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

[Tejun Heo]

Hello,

On Fri, Apr 17, 2026 at 08:43:30AM +0800, Herbert Xu wrote:
> On Thu, Apr 16, 2026 at 02:24:48PM -1000, Tejun Heo wrote:
> > The sync grow path on insert calls get_random_u32() and kvmalloc(), both of
> 
> Where does the sync grow path call kvmalloc? I think it's supposed

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.

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).

> to use GFP_ATOMIC kmalloc only.  Only the normal growth path does
> the kvmalloc for a linear hash table.  The emergency path is supposed
> to do page-by-page allocations to minimise failures.
> 
> As to get_random_u32, we can probably avoid doing it for emergency
> growing and continue to reuse the existing seed.

Oh, that's great.

Thanks.

-- 
tejun