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

[Hugh Dickins]

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@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > 
> > > 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

> 
> diff --git a/mm/mlock.c b/mm/mlock.c
> index efa6716e4dfb..9ab8042671f1 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -141,11 +141,20 @@ 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);
> +		enum vm_event_item item;
> +
>  		if (isolated || !folio_test_unevictable(folio))
> -			__count_vm_events(UNEVICTABLE_PGMUNLOCKED, nr_pages);
> +			item = UNEVICTABLE_PGMUNLOCKED;
>  		else
> -			__count_vm_events(UNEVICTABLE_PGSTRANDED, nr_pages);
> +			item = UNEVICTABLE_PGSTRANDED;
> +
> +		if (isolated) {
> +			__zone_stat_mod_folio(folio, NR_MLOCK, -nr_pages);
> +			__count_vm_events(item, nr_pages);
> +		} else {
> +			zone_stat_mod_folio(folio, NR_MLOCK, -nr_pages);
> +			count_vm_events(item, nr_pages);
> +		}
>  	}
>  
>  	/* folio_evictable() has to be checked *after* clearing Mlocked */