On Wed, Aug 16, 2023 at 03:48:49PM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: ae545c3283dc Merge tag 'gpio-fixes-for-v6.5-rc6' of git://.. > git tree: upstream > console+strace: https://syzkaller.appspot.com/x/log.txt?x=13e5d553a80000 > kernel config: https://syzkaller.appspot.com/x/.config?x=171b698bc2e613cf > dashboard link: https://syzkaller.appspot.com/bug?extid=27eece6916b914a49ce7 > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13433207a80000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=109cd837a80000 > > EXT4-fs error (device loop0): ext4_validate_block_bitmap:430: comm syz-executor211: bg 0: block 46: invalid block bitmap > Kernel panic - not syncing: EXT4-fs (device loop0): panic forced after error #syz invalid This is fundamentally a syzbot bug. The file system is horrifically corrupted, *and* the superblock has the "panic on error" (aka "panic onfile system corruption") bit set. This can be desireable because in a failover situation, if the file system is found to be corrupted, you *want* the primary server to fail, and let the secondary server to take over. This is a technique which is decades old. So this is Working As Intended, and is a classic example of (a) if you are root, you can force the file system to crash, and (b) a classic example of syzbot noise. (Five minutes of my life that I'm never getting back. :-) - Ted
