netdev - Re: Massive hash collisions on FIB

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] [day] [month] [year] [list]

Message-ID: <d1f402df-f4cc-4c31-b590-d13de9cea028@orange.com>
Date: Wed, 25 Sep 2024 23:26:55 +0200
From: Alexandre Ferrieux <alexandre.ferrieux@...il.com>
To: Eric Dumazet <edumazet@...gle.com>,
 Alexandre Ferrieux <alexandre.ferrieux@...il.com>
Cc: Simon Horman <horms@...nel.org>,
 Przemek Kitszel <przemyslaw.kitszel@...el.com>, nicolas.dichtel@...nd.com,
 netdev@...r.kernel.org
Subject: Re: Massive hash collisions on FIB

On 25/09/2024 22:12, Eric Dumazet wrote:
> On Wed, Sep 25, 2024 at 9:46 PM Alexandre Ferrieux
>>
>>
>> [...] I was not wondering about the history behind net_hash_mix(), but more
>> generally why there are two parallel implementations of FIB insertion.
> 
> ipv6 has been done after ipv4, and by different contributors.

Okay :}

> BTW, inet6_addr_hash() does not really need the net_hash_mix() because ipv6 uses
> a per-netns hashtable (net->ipv6.inet6_addr_lst[]), with pros and cons
> (vs IPv4 resizable hashtable)

Interesting. I somehow felt that the system-wide IPv4 resizable table was a good
idea in terms of scaling, as it amortizes the necessary overheads in the case of
many-netns (though it is monotonic: grows but never shrinks !)... But now I
wonder: why is it a good idea for v4 and not for v6 ?