[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANp29Y7jbcOw_rS5vbfWNo7Y+ySYhYS-AWC356QN=JRVOm9B8w@mail.gmail.com>
Date: Thu, 17 Aug 2023 16:28:33 +0200
From: Aleksandr Nogikh <nogikh@...gle.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: syzbot <syzbot+27eece6916b914a49ce7@...kaller.appspotmail.com>,
adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, nathan@...nel.org, ndesaulniers@...gle.com,
syzkaller-bugs@...glegroups.com, trix@...hat.com
Subject: Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic
forced after error (3)
On Thu, Aug 17, 2023 at 4:21 PM Theodore Ts'o <tytso@....edu> wrote:
>
> 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.
The console log has the following line:
[ 60.708717][ T5061] Kernel panic - not syncing: EXT4-fs (device
loop0): panic forced after error
Can we consider a "panic forced after error" line to be a reliable
indicator that syzbot must ignore the report?
>
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20230817142103.GA2247938%40mit.edu.
Powered by blists - more mailing lists