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: <173249179605.1734440.169960974865430595@noble.neil.brown.name>
Date: Mon, 25 Nov 2024 10:43:16 +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 Mon, 25 Nov 2024, Herbert Xu wrote:
> 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.
> 

So please turn it into a WARN_ON_ONCE and don't allow the code to return
it.

NeilBrown