Re: [PATCH for-7.1-fixes 1/2] rhashtable: add no_sync_grow option

[Herbert Xu]

On Thu, Apr 16, 2026 at 02:53:41PM -1000, Tejun Heo wrote:
> 
> Oops, that's a mistake. I meant GFP_ATOMIC kmalloc allocation. kmalloc uses
> regular spin_lock so can't be called under raw_spin_lock. There's the new
> kmalloc_nolock() but that means even smaller reserve size, so higher chance
> of failing. I'm not sure it can even accomodate larger allocations.

We should at least try to grow even if it fails.

> Another aspect is that for some use cases, it's more problematic to fail
> insertion than delaying hash table resize (e.g. that can lead to fork
> failures on a thrashing system).

rhashtable is meant to grow way before you reach 100% occupancy.
So the fact that you even reached this point means that something
has gone terribly wrong.

Is this failure reproducible?

I had a look at kernel/sched/ext.c and all the calls to rhashtable
insertion come from thread context.  So why does it even use a
raw spinlock?

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt