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

[Liam R. Howlett]

On 26/04/21 02:30PM, Pedro Falcato wrote:
> 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.

Yes.  This is almost certainly a locking issue.

Probably this one [1].

I have code to try and detect silly locking errors that I'm planning to
send out soon.

[1]. https://lore.kernel.org/all/0349d72d-dff8-4f9f-b448-919fa5ae96da@xxxxxxxxx/#t