Re: [syzbot] [mm?] BUG: sleeping function called from invalid context in __zap_vma_range

From: Pedro Falcato

Date: Tue Apr 21 2026 - 09:31:00 EST


On Mon, Apr 20, 2026 at 02:36:21PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: c1f49dea2b8f Merge tag 'mm-hotfixes-stable-2026-04-19-00-1..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=142514ce580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6a29a582d8ced859
> dashboard link: https://syzkaller.appspot.com/bug?extid=4cc5bc01fb4a179c4ffa
> compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
>
> 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-c1f49dea.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/402c79548d6e/vmlinux-c1f49dea.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/1bc39526d7f4/bzImage-c1f49dea.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+4cc5bc01fb4a179c4ffa@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> BUG: sleeping function called from invalid context at mm/memory.c:2007
> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5913, name: cmp
> preempt_count: 0, expected: 0
> RCU nest depth: 1, expected: 0
> 2 locks held by cmp/5913:
> #0: ffff88801b8cc078 (&mm->mmap_lock){++++}-{4:4}, at: mmap_read_lock include/linux/mmap_lock.h:592 [inline]
> #0: ffff88801b8cc078 (&mm->mmap_lock){++++}-{4:4}, at: exit_mmap+0x124/0xa10 mm/mmap.c:1284
> #1: ffffffff8e7e5460 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
> #1: ffffffff8e7e5460 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
> #1: ffffffff8e7e5460 (rcu_read_lock){....}-{1:3}, at: __pte_offset_map+0x2f/0x310 mm/pgtable-generic.c:290

This first looked to me like some spot where we forgot to unmap the PTE, but a
closer look suggests that, since we no longer hold the pte lock, something
forgot to unlock the rcu lock and we're just seeing the lock nesting in action.

Possibly related to the swap rework or so? I dunno. Hard to guess without
more clues. I tried looking at the mm changes for the cycle but nothing
seemed to pop out to me.

--
Pedro