Date: Thu, 25 Jan 2024 17:55:17 +0100
From: Christian Brauner <brauner@...nel.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: syzbot <syzbot+fb337a5ea8454f5f1e3f@...kaller.appspotmail.com>, 
	hdanton@...a.com, jack@...e.cz, jfs-discussion@...ts.sourceforge.net, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, shaggy@...nel.org, 
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [jfs?] INFO: task hung in path_mount (2)

On Thu, Jan 25, 2024 at 09:51:43AM -0700, Jens Axboe wrote:
> On 1/25/24 9:47 AM, Christian Brauner 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@...nel.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@...e.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.
> >>
> >> 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?
> > 
> > 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 have no better answers than this tbh. And fwiw, apart from this one I
> > haven't closed a single bug based on this.
> 
> Oh yeah, it wasn't directed at you specifically, just the overall class
> of bugs that get closed due to this in general.
> 
> > And yes, ideally the ability to write to mounted block devices should be
> > turned off. But we'll have to let it trickle into the individual
> > distributions first and make remaining userspace tools that rely on this
> > move to alternate apis before we can make any serious effort.
> 
> Hopefully it's all fine on the distro front and we can just make it the
> default some years from now. May even make sense to backport some of
> this to stable and get it in their hands faster?

Yes, I agree that this would be good.

Powered by blists - more mailing lists