netdev - Re: [RFC net-next] ipv6: Attempt to improve options code parsing

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: <989297896.30838930.1628006793490.JavaMail.zimbra@uliege.be>
Date:   Tue, 3 Aug 2021 18:06:33 +0200 (CEST)
From:   Justin Iurman <justin.iurman@...ege.be>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        yoshfuji@...ux-ipv6.org, dsahern@...nel.org, tom@...bertland.com
Subject: Re: [RFC net-next] ipv6: Attempt to improve options code parsing

>> As per Eric's comment on a previous patchset that was adding a new HopbyHop
>> option, i.e. why should a new option appear before or after existing ones in the
>> list, here is an attempt to suppress such competition. It also improves the
>> efficiency and fasten the process of matching a Hbh or Dst option, which is
>> probably something we want regarding the list of new options that could quickly
>> grow in the future.
>> 
>> Basically, the two "lists" of options (Hbh and Dst) are replaced by two arrays.
>> Each array has a size of 256 (for each code point). Each code point points to a
>> function to process its specific option.
>> 
>> Thoughts?
>> 
> Hi Justin
> 
> I think this still suffers from indirect call costs (CONFIG_RETPOLINE=y),
> and eventually use more dcache.

Agree with both. It was the compromise for such a solution, unfortunately.

> Since we only deal with two sets/arrays, I would simply get rid of them
> and inline the code using two switch() clauses.

Indeed, this is the more efficient. However, we still have two "issues":
 - ip6_parse_tlv will keep growing and code could look ugly at some point
 - there is still a "competition" between options, i.e. "I want to be at the top of the list"

Anyway, your solution is better than the current one so it's probably the way to go right now.