Re: [syzbot] [mm?] WARNING in __mod_zone_page_state

[Shakeel Butt <shakeel.butt@linux.dev>]

On Sat, Aug 29, 2026 at 08:26:02PM -0700, Hugh Dickins wrote:
> On Sat, 29 Aug 2026, Shakeel Butt wrote:
> 
> > +hugh
> > 
> > On Sat, Aug 29, 2026 at 04:03:35PM -0700, Shakeel Butt wrote:
> > > On Sat, Aug 29, 2026 at 10:52:26AM -0700, syzbot wrote:
> > > > Hello,
> > > > 
> > > > syzbot found the following issue on:
> > > > 
> > > > HEAD commit:    818bebeb63dd drm/xe: Don't hand out the flat CCS storage a..
> > > > git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=10286d79580000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=cd2073ee6d958a8d0fcd
> > > > compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13cf7625580000
> > > > 
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+cd2073ee6d958a8d0fcd@syzkaller.appspotmail.com
> > > > 
> > > > smpboot: CPU 1 is now offline
> > > > ------------[ cut here ]------------
> > > > IS_ENABLED(CONFIG_PREEMPT_COUNT) && __lockdep_enabled && (preempt_count() == 0 && this_cpu_read(hardirqs_enabled))
> > > > WARNING: mm/vmstat.c:361 at __mod_zone_page_state+0x96/0x190 mm/vmstat.c:361, CPU#2: syz-executor412/6040
> > > > Modules linked in:
> > > > CPU: 2 UID: 0 PID: 6040 Comm: syz-executor412 Not tainted syzkaller #0 PREEMPT(full) 
> > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> > > > RIP: 0010:__mod_zone_page_state+0x96/0x190 mm/vmstat.c:361
> > > > Code: d0 00 00 00 8b 05 3e 44 ea 0e 85 c0 74 1f 65 8b 05 87 e0 2e 12 65 0b 05 d0 99 2e 12 75 0f 65 8b 05 d3 db 2e 12 85 c0 74 04 90 <0f> 0b 90 48 c7 c7 c0 e7 ff 8b e8 3b b3 6d 09 65 48 0f be 5d 00 48
> > > > RSP: 0018:ffffc9000627f8e0 EFLAGS: 00010202
> > > > RAX: 0000000000000001 RBX: 0000000000000000 RCX: 1ffffffff2287150
> > > > RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88807ffd79b8
> > > > RBP: ffffffff9489f448 R08: 0000000000000001 R09: 0000000000000000
> > > > R10: 0000000000000001 R11: 0000000000000000 R12: ffffffffffffffff
> > > > R13: 0000000000000008 R14: ffff88807ffd7940 R15: ffffffff9489f440
> > > > FS:  00005555785ce400(0000) GS:ffff8880d5da2000(0000) knlGS:0000000000000000
> > > > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > > CR2: 00005608d531ffb8 CR3: 000000002cb7c000 CR4: 0000000000352ef0
> > > > Call Trace:
> > > >  <TASK>
> > > >  __zone_stat_mod_folio include/linux/vmstat.h:410 [inline]
> > > >  __munlock_folio mm/mlock.c:144 [inline]
> > > >  mlock_folio_batch+0xf97/0x36e0 mm/mlock.c:204
> > > >  mlock_drain_remote+0xe5/0x140 mm/mlock.c:230
> > > 
> > > So, we are calling stat update functions which requires preemption disabled
> > > (because they access per cpu data) an offlined CPU which is fine but we have
> > > warning that preemption is not disabled.
> > > 
> > > Let see if syzbot comes up with a reproducer. We can just simply take the local
> > > locks like neighboring functions or something else.
> > 
> > After looking deeper and it seems like __munlock_folio is the only one which
> > have a code path where lru lock with irq disabled is not done before call
> > __zone_stat_mod_folio. I think we can easily fix __munlock_folio without
> > acquiring local_locks here.
> > 
> > Something like below. I will run some tests before proposing a formal patch.
> 
> Thanks for looking into this, Shakeel, but I don't think complicating
> __munlock_folio() is at all the right fix. This is peculiar to the use
> by mlock_drain_remote(), isn't it? Which is not taking the usual local_lock
> because the CPU is going offline. I would say, just take the local_lock in
> mlock_drain_remote(), but (I haven't read the history) for all I know,
> there may be PREEMPT_RT reasons why that would be completely wrong.
> 
> Hugh

Thanks Hugh, I will explore the local_lock approach. BTW I simplified the
fix to the following. is this still making things more complicated?

diff --git a/mm/mlock.c b/mm/mlock.c
index efa6716e4dfb..fa30ffed76ab 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -141,11 +141,16 @@ static struct lruvec *__munlock_folio(struct folio *folio, struct lruvec *lruvec
 
 munlock:
 	if (folio_test_clear_mlocked(folio)) {
-		__zone_stat_mod_folio(folio, NR_MLOCK, -nr_pages);
+		/*
+		 * This runs both with and without the lruvec lock held, and
+		 * mlock_drain_remote() reaches it fully preemptible, so use
+		 * the accessors that serialize themselves.
+		 */
+		zone_stat_mod_folio(folio, NR_MLOCK, -nr_pages);
 		if (isolated || !folio_test_unevictable(folio))
-			__count_vm_events(UNEVICTABLE_PGMUNLOCKED, nr_pages);
+			count_vm_events(UNEVICTABLE_PGMUNLOCKED, nr_pages);
 		else
-			__count_vm_events(UNEVICTABLE_PGSTRANDED, nr_pages);
+			count_vm_events(UNEVICTABLE_PGSTRANDED, nr_pages);
 	}
 
 	/* folio_evictable() has to be checked *after* clearing Mlocked */
--