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: <d8022629-0359-34b7-ccae-bb12b190e43b@gmail.com>
Date:   Wed, 5 Jun 2019 09:33:19 -0600
From:   David Ahern <dsahern@...il.com>
To:     Lorenzo Colitti <lorenzo@...gle.com>,
        David Ahern <dsa@...ulusnetworks.com>
Cc:     Hangbin Liu <liuhangbin@...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 6/4/19 10:58 PM, Lorenzo Colitti wrote:
> 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?

The list of fib rules is walked looking for a match. more rules = more
overhead. Given the flexibility of the rules, I have not come up with
any changes that have a real improvement in that overhead. VRF, which
uses policy routing, was changed to have a single l3mdev rule for all
VRFs for this reason.