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

On Mon, Nov 25, 2024 at 10:09:43AM +1100, NeilBrown wrote:
>
> 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.

I just explained to you that it's extremely unlikely (e.g., less
than the chance of a cosmic ray flipping your DRAM) for you to get
EBUSY.

Not only do you have to have an extremely long hash chain (> 16)
to get EBUSY, you also need to have a hash table that is less than
75% full, and that there is an outstanding rehash on the table.

Admittedly the last condition is a bit loose right now because it
also includes routine rehashes such as growing/shrinking and I will
fix that up.

So there is no reason why you should handle EBUSY, it chould be
turned into a WARN_ON_ONCE.

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