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

[Tejun Heo <tj@kernel.org>]

Hello,

On Fri, Apr 17, 2026 at 03:51:20PM +0800, Herbert Xu wrote:
> rhashtable originated in networking where it tries very hard to
> stop the hash table from ever degenerating into a linked list.

I see.

> If your use-case is not as adversarial as that, and you're happy
> for the hash table to degenerate into a linked-list in the worst
> case, then yes it's aboslutely fine to not grow the table (or
> try to grow it and fail with kmalloc_nolock).

My use case is a bit different. I want a resizable hashtable which can be
used under raw spinlock and doesn't fail unnecessarily. My only adversary is
memory pressure and operation failures can be harmful. ie. If the system is
under severe memory pressure, hashtable becoming temporarily slower is not a
big problem as long as it restores reasonable operation once the system
recovers. However, if the insertion operation fails under e.g. sudden
network rx burst that drains atomic reserve, that can lead to fatal failure
- e.g. forks failing out of blue on a busy but mostly okay system. I think
this pretty much requires all hashtable growths to be asynchronous.

> It's just that we haven't had any users like this until now and
> the feature that you want got removed because of that.
> 
> I'm more than happy to bring it back (commit 5f8ddeab10ce).

That'd be great but looking at the commit, I'm not sure it reliably avoids
allocation in the synchronous path.

Thanks.

-- 
tejun