netdev - Re: rhashtable issue

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: <173248978347.1734440.11538643613787576556@noble.neil.brown.name>
Date: Mon, 25 Nov 2024 10:09:43 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Herbert Xu" <herbert@...dor.apana.org.au>
Cc: "Kent Overstreet" <kent.overstreet@...ux.dev>,
 "Thomas Graf" <tgraf@...g.ch>, netdev@...r.kernel.org
Subject: Re: rhashtable issue - -EBUSY

On Sun, 24 Nov 2024, Herbert Xu wrote:
> On Sun, Nov 24, 2024 at 09:01:26PM +1100, NeilBrown wrote:
> >
> > But I don't see any justification for refusing an insertion because we
> > haven't achieved the short chains yet.  Certainly a WARN_ON_ONCE or a
> > rate-limited WARN_ON might be appropriate.  Developers should be told
> > when their hash function isn't good enough.
> > But requiring developers to test for errors and to come up with some way
> > to manage them (sleep and try again is all I can think of) doesn't help anyone.
> 
> If someone can show me this occurring in a situation other than
> that where multiple entries with identical keys are being added
> to the hash table, then I'm certainly happy to change this.
> 
> But so far every occurrence of EBUSY has turned out to be caused
> by the insertion of duplicate keys into the hash table, which
> is very much expected, and one where a solution has already been
> provided (rhltable).
> 
> If this is genuine then it can be easily proved.  Just make the
> EBUSY code-path dump the keys in the chain exceeding 16 entries,
> plus the hash secret and the total number of entries in the hash
> table plus capacity.  It should then be easy to verify.
> 

I don't think this is a reasonable position to take.

When writing code I don't only want to guard against problems that I can
reproduce.  I want to guard against any problem that is theoretically
possible.   Unless you can explain why -EBUSY is not possible, I have to
write code to handle it.

NeilBrown