Received-SPF: pass (google.com: domain of linux-kernel+bounces-104453-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 15 Mar 2024 14:29:17 +0100
From: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Aleksandr Nogikh <nogikh@google.com>, 
	syzbot <syzbot+28aaddd5a3221d7fd709@syzkaller.appspotmail.com>, axboe@kernel.dk, jmorris@namei.org, 
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-security-module@vger.kernel.org, paul@paul-moore.com, serge@hallyn.com, 
	syzkaller-bugs@googlegroups.com, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, 
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [syzbot] [hfs] general protection fault in tomoyo_check_acl (3)
Message-ID: <20240315-zugerechnet-abserviert-36a416bde350@brauner>
References: <000000000000fcfb4a05ffe48213@google.com>
 <0000000000009e1b00060ea5df51@google.com>
 <20240111092147.ywwuk4vopsml3plk@quack3>
 <bbeeb617-6730-4159-80b1-182841925cce@I-love.SAKURA.ne.jp>
 <20240314155417.aysvaktvvqxc34zb@quack3>
 <CANp29Y6uevNW1SmXi_5muEeruP0TVh9Y9xwhgKO==J3fh8oa=w@mail.gmail.com>
 <20240314172731.vj4tspj6yudztmxu@quack3>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240314172731.vj4tspj6yudztmxu@quack3>

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.