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
