On Thu, Apr 4, 2024 at 6:44 PM Yu Zhao <yuzhao@xxxxxxxxxx> wrote: > > On Thu, Apr 4, 2024 at 7:36 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > On Wed, Apr 3, 2024 at 6:08 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, 02 Apr 2024 01:03:26 -0700 syzbot <syzbot+9319a4268a640e26b72b@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > Hello, > > > > > > > > syzbot found the following issue on: > > > > > > > > HEAD commit: 317c7bc0ef03 Merge tag 'mmc-v6.9-rc1' of git://git.kernel... > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15fd40c5180000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=f64ec427e98bccd7 > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=9319a4268a640e26b72b > > > > compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 > > > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > > > Downloadable assets: > > > > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-317c7bc0.raw.xz > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/efab473d72c0/vmlinux-317c7bc0.xz > > > > kernel image: https://storage.googleapis.com/syzbot-assets/5ba3f56d362d/bzImage-317c7bc0.xz > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > > Reported-by: syzbot+9319a4268a640e26b72b@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > ------------[ cut here ]------------ > > > > WARNING: CPU: 0 PID: 30105 at mm/memcontrol.c:865 __mod_memcg_lruvec_state+0x3fa/0x550 mm/memcontrol.c:865 > > > > Modules linked in: > > > > CPU: 0 PID: 30105 Comm: syz-executor.2 Not tainted 6.9.0-rc1-syzkaller-00178-g317c7bc0ef03 #0 > > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > > > > RIP: 0010:__mod_memcg_lruvec_state+0x3fa/0x550 mm/memcontrol.c:865 > > > > Code: 45 85 e4 75 1d 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc b8 00 04 00 00 e9 80 fd ff ff 89 c6 e9 a0 fd ff ff 90 <0f> 0b 90 e9 a7 fc ff ff 48 c7 c7 18 43 e1 8f e8 32 51 f8 ff e9 5e > > > > RSP: 0018:ffffc900034beef8 EFLAGS: 00010202 > > > > RAX: 0000000000000292 RBX: 0000000000000001 RCX: 1ffffffff1fc2863 > > > > RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888024b92bc8 > > > > RBP: ffff888024b92000 R08: 0000000000000005 R09: 0000000000000000 > > > > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 > > > > R13: ffff88801c326000 R14: 0000000000000001 R15: ffff888024b92000 > > > > FS: 00007f0811bf96c0(0000) GS:ffff88806b000000(0000) knlGS:0000000000000000 > > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > > CR2: 000000000cfff1dd CR3: 000000003e4e2000 CR4: 0000000000350ef0 > > > > DR0: 0000000000000031 DR1: 0000000000000000 DR2: 0000000000000000 > > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > > > Call Trace: > > > > <TASK> > > > > __update_lru_size include/linux/mm_inline.h:47 [inline] > > > > lru_gen_update_size include/linux/mm_inline.h:199 [inline] > > > > lru_gen_add_folio+0x62d/0xe80 include/linux/mm_inline.h:262 > > > > lruvec_add_folio include/linux/mm_inline.h:323 [inline] > > > > lru_add_fn+0x3fc/0xd80 mm/swap.c:215 > > > > folio_batch_move_lru+0x243/0x400 mm/swap.c:233 > > > > > > Well it beats me. I assume we failed to update for a new case. I'll > > > toss this into -next to perhaps shed a bit of light. > > > > > > --- a/mm/memcontrol.c~__mod_memcg_lruvec_state-enhance-diagnostics > > > +++ a/mm/memcontrol.c > > > @@ -860,10 +860,12 @@ void __mod_memcg_lruvec_state(struct lru > > > case NR_ANON_THPS: > > > case NR_SHMEM_PMDMAPPED: > > > case NR_FILE_PMDMAPPED: > > > - WARN_ON_ONCE(!in_task()); > > > + if (WARN_ON_ONCE(!in_task())) > > > + pr_warn("stat item index: %d\n", idx); > > > break; > > > default: > > > - VM_WARN_ON_IRQS_ENABLED(); > > > + if (VM_WARN_ON_IRQS_ENABLED()) > > > + pr_warn("stat item index: %d\n", idx); > > > > Line 865 from this commit should be this warning (i.e. warning because > > IRQs are enabled). This also makes sense because __update_lru_size() > > should not be updating any of the above stats. > > > > folio_batch_move_lru() in the above call stack should be acquiring the > > lock with IRQs disabled though, so I am not sure what's going on from > > a quick look. > > > > Adding Yu Zhao here. > > Probably an RT build where _irqsave doesn't disable IRQ? Yeah, that's possible. I don't have enough familiarity with RT to know for sure. Perhaps lruvec->lru_lock needs to be changed to a raw_spinlock_t? I am not sure if that's the correct course of action.
