[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4817f6db-bd55-2885-ac16-6fc7d6879b7e@gmail.com>
Date: Thu, 27 Sep 2018 15:18:58 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Cong Wang <xiyou.wangcong@...il.com>,
Eric Dumazet <eric.dumazet@...il.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Jiri Pirko <jiri@...nulli.us>,
Jamal Hadi Salim <jhs@...atatu.com>,
Vlad Buslov <vladbu@...lanox.com>
Subject: Re: [Patch net-next] net_sched: fix an extack message in
tcf_block_find()
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.
Powered by blists - more mailing lists