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
