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.
