Received-SPF: pass (google.com: domain of linux-kernel+bounces-39921-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 26 Jan 2024 10:28:48 +0100
From: Christian Brauner <brauner@kernel.org>
To: Aleksandr Nogikh <nogikh@google.com>
Cc: Jens Axboe <axboe@kernel.dk>, 
	syzbot <syzbot+fb337a5ea8454f5f1e3f@syzkaller.appspotmail.com>, hdanton@sina.com, jack@suse.cz, 
	jfs-discussion@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, 
	shaggy@kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)
Message-ID: <20240126-ferkel-verkraften-c13bc68f6c88@brauner>
References: <00000000000083513f060340d472@google.com>
 <000000000000e5e71a060fc3e747@google.com>
 <20240125-legten-zugleich-21a988d80b45@brauner>
 <11868eb4-0528-4298-b8bc-2621fd1aac83@kernel.dk>
 <20240125-addition-audienz-c955ab3c8435@brauner>
 <CANp29Y69y5Ctmcrf4SFFrMAD1hzsx+GYriDaa9q=3aexRspaxw@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANp29Y69y5Ctmcrf4SFFrMAD1hzsx+GYriDaa9q=3aexRspaxw@mail.gmail.com>

On Thu, Jan 25, 2024 at 07:24:01PM +0100, Aleksandr Nogikh wrote:
> On Thu, Jan 25, 2024 at 5:47 PM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Thu, Jan 25, 2024 at 09:11:34AM -0700, Jens Axboe wrote:
> > > On Thu, Jan 25, 2024 at 9:08?AM Christian Brauner <brauner@kernel.org> wrote:
> > > >
> > > > On Thu, Jan 25, 2024 at 03:59:03AM -0800, syzbot wrote:
> > > > > syzbot suspects this issue was fixed by commit:
> > > > >
> > > > > commit 6f861765464f43a71462d52026fbddfc858239a5
> > > > > Author: Jan Kara <jack@suse.cz>
> > > > > Date:   Wed Nov 1 17:43:10 2023 +0000
> > > > >
> > > > >     fs: Block writes to mounted block devices
> > > > >
> > > > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13175a53e80000
> > > > > start commit:   2ccdd1b13c59 Linux 6.5-rc6
> > > > > git tree:       upstream
> > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=9c37cc0e4fcc5f8d
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=fb337a5ea8454f5f1e3f
> > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=17ba5d53a80000
> > > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14265373a80000
> > > > >
> > > > > If the result looks correct, please mark the issue as fixed by replying with:
> > > >
> > > > #syz fix: fs: Block writes to mounted block devices
> > >
> > > Like Dave replied a few days ago, I'm kind of skeptical on all of these
> > > bugs being closed by this change. I'm guessing that they are all
> > > resolved now because a) the block writes while mounted option was set to
> > > Y, and b) the actual bug is just masked by that.
> 
> Yes, that's true. For a) there are also two sub-reasons:
> 1) The bug itself is indeed no longer reproducible because of this new
> kernel option.
> 2) The bug is not reproducible because the change broke the way
> syzkaller did the mounts -- we used to hold an fd to the loop device
> while doing the mount. That was fixed[1] soon after the commit reached
> torvalds, but for bisections syzbot has to build syzkaller exactly at
> the revision when the reproducer was found (otherwise it may parse the
> syz reproducer incorrectly). So this kernel commit becomes exactly the
> point where the reproducer stops working.
> 
> For most of the recently closed fs bugs (2) should not be the primary
> reason though -- these fix bisections are done only when syzbot
> stopped seeing crashes with the corresponding titles, which was very
> likely caused by (1) in the first place.
> 
> [1] https://github.com/google/syzkaller/commit/551587c192ecb4df26fcdab775ed145ee69c07d4
> 
> > >
> > > Maybe this is fine, but it does seem a bit... sketchy? The bugs aren't
> > > really fixed, and what happens if someone doesn't turn on that option?
> > > If it's required, perhaps it should not be an option at all? Though
> > > that'd seem to be likely to break some funky use cases, whether they are
> > > valid or not.
> >
> > We have no way of actually testing or verifying this stuff and a lot of
> > these have been around for a long time. For example, this report here
> > has a C reproducer but following the actual dashboard link that
> > reproducer is striked-through which supposedly means that it isn't valid
> > or reliable. And no other reproducer ever showed up.
> >
> > As far as I can see we should just close reports such as. If this is a
> > real bug that is separate from the ability to mount to writed block
> > devices then one should hope that syzbot finds another reproducer that
> > let's us really analyze the bug?
> 
> Yes, if the ability to write to the block device is not really
> necessary to trigger the bug, syzbot should find it again in some
> time.
> 
> >
> > A separate issue is that syzbot keeps suggesting as all of these being
> > closable because of this. So how serious can we take this and how much
> > time can/should we spend given that we got ~20 or more of these mails in
> > the last two weeks or so.
> 
> I can add the "fs: Block writes to mounted block devices" commit to
> the black list for syzbot bisections -- it will stop sending such
> emails then.

No, I think it's helpful. I was just saying that we can't be expected to
spend hours per report to check whether this makes sense or not. I
wasn't complaining about this per se.