[syzbot] [hfs] general protection fault in tomoyo_check_acl (3)

[Christian Brauner]

On Thu, Mar 14, 2024 at 06:27:31PM +0100, Jan Kara wrote:
> Hi Aleksandr,
> 
> On Thu 14-03-24 17:21:30, Aleksandr Nogikh wrote:
> > Yes, the CONFIG_BLK_DEV_WRITE_MOUNTED=n change did indeed break our C
> > executor code (and therefore our C reproducers). I posted a fix[1]
> > soon afterwards, but the problem is that syzbot will keep on using old
> > reproducers for old bugs. Syzkaller descriptions change over time, so
> > during bisection and patch testing we have to use the exact syzkaller
> > revision that detected the original bug. All older syzkaller revisions
> > now neither find nor reproduce fs bugs on newer Linux kernel revisions
> > with CONFIG_BLK_DEV_WRITE_MOUNTED=n.
> 
> I see, thanks for explanation!
> 
> > If the stream of such bisection results is already bothering you and
> > other fs people, a very quick fix could be to ban this commit from the
> > possible bisection results (it's just a one line change in the syzbot
> > config). Then such bugs would just get gradually obsoleted by syzbot
> > without any noise.
> 
> It isn't bothering me as such but it results in
> CONFIG_BLK_DEV_WRITE_MOUNTED=n breaking all fs-related reproducers and thus
> making it difficult to evaluate whether the reproducer was somehow
> corrupting the fs image or not. Practically it means closing most
> fs-related syzbot bugs and (somewhat needlessly) starting over from scratch
> with search for reproducers. I'm OK with that although it is a bit
> unfortunate... But I'm pretty sure within a few months syzbot will deliver
> a healthy portion of new issues :)

Fwiw, my take on this is that if an active subsystem (responsive to
syzbot bugs and whatnot) is not able to fix a bug within months given a
reproducer then it's likely that the reproducer is not all that useful.

So by closing that issue and we're hopefully getting a better
reproducer.