[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <173248978347.1734440.11538643613787576556@noble.neil.brown.name>
Date: Mon, 25 Nov 2024 10:09:43 +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 Sun, 24 Nov 2024, Herbert Xu wrote:
> On Sun, Nov 24, 2024 at 09:01:26PM +1100, NeilBrown wrote:
> >
> > 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.
>
> If someone can show me this occurring in a situation other than
> that where multiple entries with identical keys are being added
> to the hash table, then I'm certainly happy to change this.
>
> But so far every occurrence of EBUSY has turned out to be caused
> by the insertion of duplicate keys into the hash table, which
> is very much expected, and one where a solution has already been
> provided (rhltable).
>
> If this is genuine then it can be easily proved. Just make the
> EBUSY code-path dump the keys in the chain exceeding 16 entries,
> plus the hash secret and the total number of entries in the hash
> table plus capacity. It should then be easy to verify.
>
I don't think this is a reasonable position to take.
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.
NeilBrown
Powered by blists - more mailing lists