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: <Z0O0BV6v4x3mq-Uw@gondor.apana.org.au>
Date: Mon, 25 Nov 2024 07:17:25 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: NeilBrown <neilb@...e.de>, Thomas Graf <tgraf@...g.ch>,
	netdev@...r.kernel.org
Subject: Re: rhashtable issue - -EBUSY

On Sun, Nov 24, 2024 at 05:35:56PM -0500, Kent Overstreet wrote:
>
> That's what I've been describing, but you keep insisting that this must
> be misuse, even though I'm telling you I've got the error code that
> shows what is going on.

Well, please do as I suggested and dump the chain with over 16
entries when this happens.  If you can prove to me that you've
got 16 entries with non-identical keys that hashed to the same
bucket then I will fix this.  Please also dump the table size
and the total number of entries currently hashed.

As I said, every single report in the past has turned out to be
because people were adding multiple entries with identical keys
to the same hash table, which will obviously breach the limit of
16.

But I think there is one thing that I will do, the rehash check
is a bit too loose.  It should only fail if the outstanding rehash
was caused by insertion failure, and not if it was a growth or
shrink operation.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt