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: <t3a3ggvcvnle6dnnmzf3ehlgcxhgpnn2mbpyukjv3g67iqxlah@spqeyovloafo>
Date: Mon, 25 Nov 2024 22:12:44 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: NeilBrown <neilb@...e.de>, Thomas Graf <tgraf@...g.ch>, 
	netdev@...r.kernel.org
Subject: Re: rhashtable issue - -EBUSY

On Tue, Nov 26, 2024 at 10:54:37AM +0800, Herbert Xu wrote:
> On Mon, Nov 25, 2024 at 07:38:57PM -0500, Kent Overstreet wrote:
> >
> > Networking and storage people seem to have quite different perspectives
> > on these issues; in filesystem and storage land in general, randomly
> > failing is flatly unacceptable.
> > 
> > We do need these issues fixed.
> > 
> > I don't think the -EBUSY is being taken seriously enough either,
> > especially given that the default hash is jhash. I've seen jhash produce
> > bad statistical behaviour before, and while rehashing with a different seen
> > may make jhash acceptable, I'm not an all confident that we won't ever
> > see -EBUSY show up in production.
> > 
> > That's the sort of issue that won't ever show up in testing, but it will
> > show up in production as users start coming up with all sorts of weird
> > workloads - and good luck debugging those...
> 
> I actually added a knob to disable EBUSY but it was removed
> without my review:
> 
> commit ccd57b1bd32460d27bbb9c599e795628a3c66983
> Author: Herbert Xu <herbert@...dor.apana.org.au>
> Date:   Tue Mar 24 00:50:28 2015 +1100
> 
>     rhashtable: Add immediate rehash during insertion
> 
> commit 5f8ddeab10ce45d3d3de8ae7ea8811512845c497
> Author: Florian Westphal <fw@...len.de>
> Date:   Sun Apr 16 02:55:09 2017 +0200
> 
>     rhashtable: remove insecure_elasticity
> 
> I could reintroduce this knob.  It should obviously also disable
> the last-ditch hash table resize that should make ENOMEM impossible
> to hit.

How odd...

Does the knob have to be insecure_elasticity? Neal's idea of just
blocking instead of returning -EBUSY seems perfectly viable to me, most
uses I'm aware of don't need insertions to be strictly nonblocking.