Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

[Christian Brauner]

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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxx>
> > > > > 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.