Messages in this thread | | | From | Aleksandr Nogikh <> | Date | Fri, 18 Aug 2023 18:46:57 +0200 | Subject | Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3) |
| |
On Fri, Aug 18, 2023 at 1:43 PM Aleksandr Nogikh <nogikh@google.com> wrote: > > 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.
Ah, it's a bit trickier -- the syz_mount_image() code is fine. The reproducer first mounts an ext4 image via syz_mount_image(), which appends "errors=continue" to the options and it doesn't lead to the panic. But then the reproducer does a direct mount() call for the loop device previously created in syz_mount_image(), this time _without_ mount options.
I've sent https://github.com/google/syzkaller/pull/4143 to sanitize plain mount() calls.
> > > On Thu, Aug 17, 2023 at 4:45 PM Theodore Ts'o <tytso@mit.edu> 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 > >
| |