* syzbot <syzbot+79fcba037b6df73756d3@xxxxxxxxxxxxxxxxxxxxxxxxx> [231023 13:24]: > syzbot has found a reproducer for the following issue on: > > HEAD commit: e8361b005d7c Add linux-next specific files for 20231023 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1207cb05680000 > kernel config: https://syzkaller.appspot.com/x/.config?x=75e8fc3570ec9a74 > dashboard link: https://syzkaller.appspot.com/bug?extid=79fcba037b6df73756d3 > compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=107fab89680000 > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/e28a7944599e/disk-e8361b00.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/7dd355dbe055/vmlinux-e8361b00.xz > kernel image: https://storage.googleapis.com/syzbot-assets/7b2a9050635d/bzImage-e8361b00.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+79fcba037b6df73756d3@xxxxxxxxxxxxxxxxxxxxxxxxx > > ============================= > WARNING: suspicious RCU usage > 6.6.0-rc6-next-20231023-syzkaller #0 Not tainted > ----------------------------- > lib/maple_tree.c:856 suspicious rcu_dereference_check() usage! > > other info that might help us debug this: > > > rcu_scheduler_active = 2, debug_locks = 1 > no locks held by syz-executor.4/5222. > > stack backtrace: > CPU: 0 PID: 5222 Comm: syz-executor.4 Not tainted 6.6.0-rc6-next-20231023-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/06/2023 > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x125/0x1b0 lib/dump_stack.c:106 > lockdep_rcu_suspicious+0x20b/0x3a0 kernel/locking/lockdep.c:6711 > mas_root lib/maple_tree.c:856 [inline] > mas_root lib/maple_tree.c:854 [inline] > mas_start lib/maple_tree.c:1385 [inline] > mas_state_walk lib/maple_tree.c:3705 [inline] > mas_walk+0x4d1/0x7d0 lib/maple_tree.c:4888 > mas_find_setup lib/maple_tree.c:5948 [inline] > mas_find+0x1e6/0x400 lib/maple_tree.c:5989 > vma_find include/linux/mm.h:952 [inline] > do_mbind+0xc8f/0x1010 mm/mempolicy.c:1328 Hugh, 41de65c4cd27 ("mempolicy: mmap_lock is not needed while migrating folios") changes the do_mbind() code locking here to drop the mmap write lock on line 1300 in e8361b005d7c. This is an issue as it opens the VMA (maple) tree to being updated, but you then re-walk the tree later. If this is okay, then you can add an rcu_read_lock()/rcu_read_unlock() to iterate over the VMAs so it is safe (around 1327/1332, respectively). I'm not entirely sure why this is safe to do without the mmap write lock, but considering the change log it seems you have thought through it. I'm just not sure what is going to stop the VMAs from being split or such by a ref count on the memory policy (or if it matters if they are)? Thanks, Liam
