> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=127d8d82580000 > > start commit: 835244aba90d Add linux-next specific files for 20250709 > > git tree: linux-next > > final oops: https://syzkaller.appspot.com/x/report.txt?x=117d8d82580000 > > console output: https://syzkaller.appspot.com/x/log.txt?x=167d8d82580000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=8396fd456733c122 > > dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=115c40f0580000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11856a8c580000 > > > > Reported-by: syzbot+01ef7a8da81a975e1ccd@xxxxxxxxxxxxxxxxxxxxxxxxx > > Fixes: 77eb64439ad5 ("fs/buffer: remove the min and max limit checks in __getblk_slow()") > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > Ah, I see what's going on here. The reproducer mounts ext4 filesystem and > sets block size on loop0 loop device to 32k using LOOP_SET_BLOCK_SIZE. Now > because there are multiple reproducer running using various loop devices it > can happen that we're setting blocksize during mount which obviously > confuses the filesystem (and makes sb mismatch the bdev block size). It is > really not a good idea to allow setting block size (or capacity for that > matter) underneath an exclusive opener. The ioctl should have required > exclusive open from the start but now it's too late to change that so we > need to perform a similar dance with bd_prepare_to_claim() as in > loop_configure() to grab temporary exclusive access... Sigh. > > Anyway, the commit 77eb64439ad5 is just a victim that switched KERN_ERR > messages in the log to WARN_ON so syzbot started to notice this breakage. I was also thinking the change we did from KERN_ERR to WARN_ON was catching a different bug. Thanks for taking a look and fixing the issue Jan. -- Pankaj Raghav
