From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [Patch net-next] net_sched: fix an extack message in tcf_block_find() Date: Thu, 27 Sep 2018 15:18:58 -0700 Message-ID: <4817f6db-bd55-2885-ac16-6fc7d6879b7e@gmail.com> References: <20180927204219.17846-1-xiyou.wangcong@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Linux Kernel Network Developers , Jiri Pirko , Jamal Hadi Salim , Vlad Buslov To: Cong Wang , Eric Dumazet Return-path: Received: from mail-pg1-f174.google.com ([209.85.215.174]:40724 "EHLO mail-pg1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725957AbeI1Ej3 (ORCPT ); Fri, 28 Sep 2018 00:39:29 -0400 Received: by mail-pg1-f174.google.com with SMTP id n31-v6so2929393pgm.7 for ; Thu, 27 Sep 2018 15:19:00 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 09/27/2018 02:36 PM, Cong Wang wrote: > I don't understand what you mean by changing ip command, you must > mean tc command, but still, I have no idea about how restarting failed > syscall could be related to my patch and why we need to restart anything > here. If the refcnt goes to 0, it will never come back, retrying won't help > anything. > Yep, tc command it is. I was not especially commenting your patch (replacing an english message by another does not seem very big deal), but the fact that the code right there seems to be prepared for parallel changes. But using RCU lookups in control path will lead to occasional failures that most user space tools would not expect. Lets assume two tasks are launching "tc qdisc replace dev eth0 root XXX" in whatever order/parallelism. Both should succeed, after/before major RTNL->other_locking_mechanism Control paths are usually using a mutex or a spinlock so that they never hit a 0-refcount at all.