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