Re: [PATCH v5 2/3] KEYS: Replace assoc_array with rhashtable

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Nov 06, 2026 at 07:25:51PM -0800, Eric Biggers wrote:
> I don't think the retry loop is actually sufficient or desirable here
> (though it would be very rare for it to be reached).  It gets reached
> when there are too many elements in one rhashtable chain.  However,
> we're already pre-hashing with SipHash, and the rhashtable level hash is
> passed only the 32-bit SipHash.  Suppose we reach this case because the
> SipHash values collided: then rhashtable's rehashing would never reduce
> the chain length, and the -EBUSY would last forever.
> 
> I think the right solution is to just set '.insecure_elasticity = true'
> in the rhashtable_params, to disable the chain length checks.  Those
> checks make no sense when we're using SipHash anyway.

Thanks, this is a valid suggestion. I  was thinking about having maximum
retries but this is much better idea. I'll address this as you proposed.


> 
> Then the retry loop would not be needed.
> 
> (And even for rhashtable users who aren't using SipHash, like
> fs/verity/, hard-failing insertions if the hash chains gets too long
> seems wrong.  I mean, imagine if the kernel started refusing to do file
> operations if one of the hash chains in the VFS hash tables happened to
> get too long...  But I guess rhashtable was designed for towards
> networking users who are able to just drop the data without much issue.
> Plus it predates SipHash existing.)
> 
> - Eric

Br, Jarkko