Re: [syzbot] [bridge?] kernel BUG in __get_vm_area_node

On Tue, May 12, 2026 at 11:26:06AM +0200, Uladzislau Rezki wrote:
> On Tue, May 12, 2026 at 11:47:54AM +0300, Ido Schimmel wrote:
> > On Sat, May 09, 2026 at 12:35:24PM -0700, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:    9207d47f966b Merge tag 'for-linus' of git://git.kernel.org..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=17e44d06580000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=d0f0911eedbc130a
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=8b12fc6e0fb139765b58
> > > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > > userspace arch: i386
> > > 
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > > 
> > > Downloadable assets:
> > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-9207d47f.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/6c5e883f31aa/vmlinux-9207d47f.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/19f3e863ae5c/bzImage-9207d47f.xz
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: [email protected]
> > > 
> > > ------------[ cut here ]------------
> > > kernel BUG at mm/vmalloc.c:3206!
> > 
> > It seems that this bug was fixed by commit 30c19366636f ("mm: fix BUG
> > splat with kvmalloc + GFP_ATOMIC"), but then commit c6307674ed82 ("mm:
> > kvmalloc: add non-blocking support for vmalloc") re-introduced it.
> > 
> > Uladzislau, can you please look into it?
> > 
> > Note that the bridge is calling rhashtable_lookup_insert_fast() with BH
> > disabled.
> > 
> Yep, since vmalloc can be called with ATOMIC/NOWAIT flags now. I am
> checking this. Probably we can just remove below check:
> 
> <snip>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 676851d5cfe7..3d338e4bcbf7 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3209,7 +3209,6 @@ struct vm_struct *__get_vm_area_node(unsigned long size,
>         struct vm_struct *area;
>         unsigned long requested_size = size;
> 
> -       BUG_ON(in_interrupt());
>         size = ALIGN(size, 1ul << shift);
>         if (unlikely(!size))
>                 return NULL;
> <snip>
> 
> We have already the check:
> 
> 	gfp_mask = gfp_mask & GFP_RECLAIM_MASK;
> 	allow_block = gfpflags_allow_blocking(gfp_mask);
> 	might_sleep_if(allow_block);
> 
> in alloc_vmap_area().
> 
Actually since we are not allowed to call vmalloc from NMI nor IRQ
context. We should keep the check. But in a slightly different form:

<snip>
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 676851d5cfe7..273bbe49eaef 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3209,7 +3209,7 @@ struct vm_struct *__get_vm_area_node(unsigned long size,
 	struct vm_struct *area;
 	unsigned long requested_size = size;
 
-	BUG_ON(in_interrupt());
+	BUG_ON(in_nmi() || in_hardirq());
 	size = ALIGN(size, 1ul << shift);
 	if (unlikely(!size))
 		return NULL;
<snip>

if any context disables BH, i.e. local_bh_disable() it does not mean we
are in IRQ context. Furthermore the documentation about in_interrupt()
says:

<snip>
/*
 * The following macros are deprecated and should not be used in new code:
 * in_softirq()   - We have BH disabled, or are processing softirqs
 * in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled
 */
#define in_softirq()		(softirq_count())
#define in_interrupt()		(irq_count())
<snip>

those are should not be used.

--
Uladzislau Rezki