netdev - Re: [net PATCH 1/2] ipv4: Restore fib_trie_flush_external function and fix call ordering

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: <20161115205233.GD1783@nanopsycho.orion>
Date:   Tue, 15 Nov 2016 21:52:33 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     "Duyck, Alexander H" <alexander.h.duyck@...el.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>
Subject: Re: [net PATCH 1/2] ipv4: Restore fib_trie_flush_external function
 and fix call ordering

Tue, Nov 15, 2016 at 09:49:02PM CET, alexander.h.duyck@...el.com wrote:
>On Tue, 2016-11-15 at 21:31 +0100, Jiri Pirko wrote:
>> Tue, Nov 15, 2016 at 09:29:09PM CET, alexander.h.duyck@...el.com wrote:
>> > 
>> > On Tue, 2016-11-15 at 20:51 +0100, Jiri Pirko wrote:
>> > > 
>> > > Tue, Nov 15, 2016 at 11:46:06AM CET, alexander.h.duyck@...el.com wrote:
>> > > > 
>> > > > 
>> > > > The patch that removed the FIB offload infrastructure was a bit too
>> > > > aggressive and also removed code needed to clean up us splitting the table
>> > > > if additional rules were added.  Specifically the function
>> > > > fib_trie_flush_external was called at the end of a new rule being added to
>> > > > flush the foreign trie entries from the main trie.
>> > > > 
>> > > > I updated the code so that we only call fib_trie_flush_external on the main
>> > > > table so that we flush the entries for local from main.  This way we don't
>> > > > call it for every rule change which is what was happening previously.
>> > > 
>> > > Well, the function was introduced by:
>> > > 
>> > > commit 104616e74e0b464d449fdd2ee2f547d2fad71610
>> > > Author: Scott Feldman <sfeldma@...il.com>
>> > > Date:   Thu Mar 5 21:21:16 2015 -0800
>> > > 
>> > >     switchdev: don't support custom ip rules, for now
>> > >     
>> > >     Keep switchdev FIB offload model simple for now and don't allow custom ip
>> > >     rules.
>> > > 
>> > > Why this was not needed before? What changed in between:
>> > > 104616e74e0b464d449fdd2ee2f547d2fad71610 ("switchdev: don't support custom ip rules, for now")
>> > > and
>> > > 347e3b28c1ba2 ("switchdev: remove FIB offload infrastructure")
>> > 
>> > We collapsed the two tables into one in commit 0ddcf43d5d4a ("ipv4: FIB
>> > Local/MAIN table collapse") which was submitted the next day.  Scott
>> > and I were working on things at the same time and the
>> > fib_table_flush_external function was something we had worked out that
>> > would allow him to take care of his use case and me to take care of
>> > cleaning up the tables after unmerging.
>> 
>> Okay. But please name the fuction differently, as it does not flush
>> external. Thanks!
>
>You and I have different meanings for "external".
>
>In my case I am flushing entries that belong to a foreign "external"
>table from the table specified. So by "external" I am referring to
>entries that don't actually live in main, but actually reside in local.
>If you take a look at fib_table_flush that gets rid of all entries,
>fib_table_flush_external simply clears the foreign ones.
>
>Also I'd rather maintain naming since it makes it easier if we need to
>backport fixes.
>
>Finally, the flag RTNH_F_EXTERNAL was renamed over a year ago in commit
>36583eb54d46c ("rename RTNH_F_EXTERNAL to RTNH_F_OFFLOAD") so there
>isn't too much likelihood of this being confused for something that
>handles offloaded entries.  If you take a look in net/ipv4/* after your
>patch there isn't actually anything that references the word external
>so the likelihood for any confusion is extremely low.

Okay. But if you can, please put a comment to this function in order to
prevent future confusion. Thanks!