netdev - Re: [patch net v2 1/4] net/sched: Change tc_action refcnt and bindcnt to atomic

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:   Mon, 23 Oct 2017 08:39:52 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Chris Mi <chrism@...lanox.com>
Cc:     Jamal Hadi Salim <jhs@...atatu.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Lucas Bates <lucasb@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>
Subject: Re: [patch net v2 1/4] net/sched: Change tc_action refcnt and bindcnt
 to atomic

On Sun, Oct 22, 2017 at 7:47 PM, Chris Mi <chrism@...lanox.com> wrote:
>
> It seems it is not easy to discard call_rcu().  I'm afraid even if we have a final solution
> without call_rcu(), it is not mature at the beginning as well. I mean we also need time

Why do you believe it is not easy? RTNL lock is already there,
list_splice_init_rcu() is there too. I can naturally divide my patches
for each module so that they are much easier to backport than
yours.

> to fix the possible bugs of the new design. And maybe to destroy the filters in parallel
> is the right direction. If this bug is the last bug brought by call_rcu(), then changing it
> may not be a good idea.

Again, you have to prove this is the last bug, I seriously doubt
it is.

>
> Patch 1 is straightforward to use atomic. Patch 2 is to convert the list to array.

Both are big in size.

> I think there is no harm to the new design.  Patch 3 and 4 are useful test case.

It definitely doesn't harm, but why do we waste time on it when we
know there is a better way? It is clearly not easy for backport either,
in fact it is harder w.r.t. size.

> We also need it with new design to make sure there is no regression.
>

Are you saying I can't trust your test cases? ;)

> So I think my patch set should not be held so long time.

I think your patches should be dropped except the last two,
I will take the last two for you.

Thanks!