I've taken a closer look at the issue. Documentation/filesystems/ext4.txt says that the "errors=" mount parameter "override the errors behavior specified in the superblock". So syzbot can prevent it by passing "errors=continue" as a mount argument and there's no need to filter out such reports. Syzkaller actually already does that in the C reproducer. It just seems that this time the tool has mutated the mount options so much that the simple patching no longer worked (most likely because of \0 characters in between). I'll update the syz_mount_image() code. On Thu, Aug 17, 2023 at 4:45 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Thu, Aug 17, 2023 at 04:28:33PM +0200, Aleksandr Nogikh wrote: > > 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? > > Yes. And the file system image that generated this bug should be > discarded, because otherwise successive mutations will generate a > large number of crashes that syzbot will then need to ignore, thus > consuming syzbot resources. > > Alternatively, you can do the moral equivalent of "tune2fs -e continue > foo.img" on any mutated file system seed, which will clear the "panic > on error". > > (The other alternative is "tune2fs -e remount-ro", but given syzbot's > desire to find kernel crashes, "tune2fs -e continue" is more likely > find ways in which the kernel will find itself into trouble. Some > sysadmins will want to chose "remount-ro", however, since that is more > likely to limit file system damage once the file system is discovered > to be corrupted.) > > - Ted >
