On Thu, Mar 14, 2024 at 06:27:31PM +0100, Jan Kara wrote: > Hi Aleksandr, > > On Thu 14-03-24 17:21:30, Aleksandr Nogikh wrote: > > Yes, the CONFIG_BLK_DEV_WRITE_MOUNTED=n change did indeed break our C > > executor code (and therefore our C reproducers). I posted a fix[1] > > soon afterwards, but the problem is that syzbot will keep on using old > > reproducers for old bugs. Syzkaller descriptions change over time, so > > during bisection and patch testing we have to use the exact syzkaller > > revision that detected the original bug. All older syzkaller revisions > > now neither find nor reproduce fs bugs on newer Linux kernel revisions > > with CONFIG_BLK_DEV_WRITE_MOUNTED=n. > > I see, thanks for explanation! > > > If the stream of such bisection results is already bothering you and > > other fs people, a very quick fix could be to ban this commit from the > > possible bisection results (it's just a one line change in the syzbot > > config). Then such bugs would just get gradually obsoleted by syzbot > > without any noise. > > It isn't bothering me as such but it results in > CONFIG_BLK_DEV_WRITE_MOUNTED=n breaking all fs-related reproducers and thus > making it difficult to evaluate whether the reproducer was somehow > corrupting the fs image or not. Practically it means closing most > fs-related syzbot bugs and (somewhat needlessly) starting over from scratch > with search for reproducers. I'm OK with that although it is a bit > unfortunate... But I'm pretty sure within a few months syzbot will deliver > a healthy portion of new issues :) Fwiw, my take on this is that if an active subsystem (responsive to syzbot bugs and whatnot) is not able to fix a bug within months given a reproducer then it's likely that the reproducer is not all that useful. So by closing that issue and we're hopefully getting a better reproducer.
