Re: [PATCH 4/4] rhashtable: fix vmalloc() deadlock in atomic rehash

[Herbert Xu <herbert@gondor.apana.org.au>]

On Wed, Nov 04, 2026 at 12:11:24PM +0100, Uladzislau Rezki wrote:
>
> There are users in kernel. For example:

Thanks for the list.

> drivers/GPU
>     /* Allocate the file in vmalloc memory, it's likely to be big */
>     iter.start = __vmalloc(file_size, GFP_NOWAIT);
> 
> AMD-GPU:
>     kvzalloc(size, GFP_NOWAIT);
>     kvzalloc_objs(struct amdgpu_coredump_ring, GFP_NOWAIT);
>     kvzalloc(ring->ring_size, GFP_NOWAIT);

These appear to be executing out of process context without spin
locks so they're not really GFP_ATOMIC.

> Virtio ring-testing:
>     (alloc_ring(0)), gfpflags_allow_blocking(0) does not allow blocking.

I didn't really look into this as it's just test code.

> net/ipv4/udp.c:
>     err = bpf_iter_udp_realloc_batch(iter, batch_sks, GFP_NOWAIT);

This looks buggy in exactly the same way as rhashtable.  It's
called under spin_lock_bh, and the same lock can be taken on
the softirq path on another CPU.

So are there any safe users of kvmalloc with GFP_ATOMIC? If not
I suggest that we change kvmalloc to disallow vmalloc when called
with GFP_ATOMIC.

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