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: <lm4aynuzpvsnurr4kzkecwantceebugrija2hxjrwou4r4u7ea@xxtncggxnbk2>
Date: Sun, 24 Nov 2024 17:35:04 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: NeilBrown <neilb@...e.de>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, Thomas Graf <tgraf@...g.ch>, 
	netdev@...r.kernel.org
Subject: Re: rhashtable issue - -EBUSY

On Sun, Nov 24, 2024 at 09:01:26PM +1100, NeilBrown wrote:
> On Sun, 24 Nov 2024, Herbert Xu wrote:
> > On Sun, Nov 24, 2024 at 08:25:38PM +1100, NeilBrown wrote:
> > >
> > > Failure should not just be extremely unlikely.  It should be
> > > mathematically impossible. 
> > 
> > Please define mathematically impossible.  If you mean zero then
> > it's pointless since modern computers are known to have non-zero
> > failure rates.
> 
> mathematically assuming perfect hardware.  i.e.  an analysis of the
> software would show there is no way for an error to be returned.
> 
> > 
> > If you have a definite value in mind, then we could certainly
> > tailor the maximum elasticity to achieve that goal.
> 
> I don't think there is any need to change the elasticity.  Rehashing
> whenever the longest chain reaches 16 seems reasonable - though some
> simple rate limiting to avoid a busy-loop with a bad hash function would
> not be unwelcome.
> 
> 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.

Agreed, sleep until the rehash finishes seems like what we're after, and
that should be in the rhashtable code.