[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <173257789029.1734440.16216135574521669815@noble.neil.brown.name>
Date: Tue, 26 Nov 2024 10:38:10 +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:43:16AM +1100, NeilBrown wrote:
> >
> > So please turn it into a WARN_ON_ONCE and don't allow the code to return
> > it.
>
> You still have to handle ENOMEM, right?
I'd rather not. Why is ENOMEM exposed to the caller?
The rehash thread should *always* allocated the *whole* table before
adding it to the chain and starting to rehash into it. Until that
allocation succeeds, just keeping inserting in the existing table.
rhashtables seems to have been written with an understanding that long
hash chains are completely unacceptable and failure to insert is
preferred. I accept that in some circumstances that might be true, but
in other circumstances failure to insert (except for -EEXIST) is
anathema and long hash chains are simply unfortunate.
Now I could write an alternate resizable hashtable implementation which
values predictable behaviour over short chains, but it would only be a
tiny bit different from rhashtables so it seems to make more sense to
add that option into rhashtables (which already has several options for
different use cases).
So I don't ever want -E2BIG either. Either -EEXIST or success should be
the only possible results of "insert".
Thanks,
NeilBrown
>
> 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
>
Powered by blists - more mailing lists