On Thu, 2 Jan 2025 at 18:19, 'Aleksandr Nogikh' via syzkaller-bugs <syzkaller-bugs@xxxxxxxxxxxxxxxx> wrote: > > On Thu, Jan 2, 2025 at 11:26 AM 'Lorenzo Stoakes' via syzkaller-bugs > <syzkaller-bugs@xxxxxxxxxxxxxxxx> wrote: > > > > Happy new year! > > Happy New Year! :) > > > > > On Tue, Dec 31, 2024 at 08:50:23PM -0800, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 8379578b11d5 Merge tag 'for-v6.13-rc' of git://git.kernel... > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16113018580000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=d269ef41b9262400 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=46423ed8fa1f1148c6e4 > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > > userspace arch: i386 > > > > Hmmmm 32-bit? But kernel reports give 64-bit registers? So I guess 32-bit > > userland, 64-bit kernel? > > Yes, that's a 32-bit userspace binary running on a 64-bit kernel. > > > > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > Hmm. Racey thing? > > > > > > > > Downloadable assets: > > > disk image: https://storage.googleapis.com/syzbot-assets/86d2e3352aff/disk-8379578b.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/345570cd3573/vmlinux-8379578b.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/01da37a51505/bzImage-8379578b.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+46423ed8fa1f1148c6e4@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 > > > R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 > > > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > > </TASK> > > > ------------[ cut here ]------------ > > > WARNING: CPU: 1 PID: 20504 at mm/vma.c:734 vma_merge_existing_range+0x1145/0x16f0 mm/vma.c:734 > > > > It'd be nice if syzbot could actually print the code that generates the > > warning :) a nice-to-have perhaps. > > Thanks for the suggestion! > I've filed https://github.com/google/syzkaller/issues/5654 It may be better for the kernel to do it. Then it would benefit all testing systems, and most manual testing/reports as well. Since WARN_ON is a macro, it should be trivial to capture the condition string. I guess some embed kernels will want to turn it off, so probably should be configurable.
