netdev - Re: [Patch net-next] net_sched: fix an extack message in tcf_block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.