netdev - Re: [PATCH net] fib_rules: return 0 directly if an exactly same rule exists when NLM_F

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]

Message-ID: <CAKD1Yr30Wj+Kk-ao2tFLU5apNjAVNYKeYJ+jZsb=5HTtd3+5-Q@mail.gmail.com>
Date:   Wed, 5 Jun 2019 13:58:18 +0900
From:   Lorenzo Colitti <lorenzo@...gle.com>
To:     David Ahern <dsa@...ulusnetworks.com>
Cc:     Hangbin Liu <liuhangbin@...il.com>,
        David Ahern <dsahern@...il.com>,
        David Miller <davem@...emloft.net>,
        Yaro Slav <yaro330@...il.com>,
        Thomas Haller <thaller@...hat.com>,
        Alistair Strachan <astrachan@...gle.com>,
        Greg KH <greg@...ah.com>,
        Linux NetDev <netdev@...r.kernel.org>,
        Mateusz Bajorski <mateusz.bajorski@...ia.com>,
        Maciej Żenczykowski <zenczykowski@...il.com>
Subject: Re: [PATCH net] fib_rules: return 0 directly if an exactly same rule
 exists when NLM_F_EXCL not supplied

On Wed, Jun 5, 2019 at 12:58 PM David Ahern <dsa@...ulusnetworks.com> wrote:
> I think it is crazy to add multiple identical rules given the linear
> effect on performance.

Not sure if this is what you were implying or not, but our code
doesn't maintain multiple identical rules in steady state. It only
uses them for make-before-break when something changes.

> But, since it breaks Android, it has to be reverted.

Well... the immediate problem on Android is that we cannot live with
this going to LTS, since it is going to break devices in the field.

As for making this change in 5.3: we might be able to structure the
code differently in a future Android release, assuming the same
userspace code can work on kernels back to 4.4 (not sure it can, since
the semantics changed in 4.8). But even if we can fix this in Android,
this change is still breaking compatibility with existing other
userspace code. Are there concrete performance optimizations that
you'd like to make that can't be made unless you change the semantics
here? Are those optimizations worth breaking the backwards
compatibility guarantees for?