Re: [syzbot] [ext4?] WARNING in bdev_getblk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri 11-07-25 05:27:01, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 77eb64439ad52d8afb57bb4dae24a2743c68f50d
> Author: Pankaj Raghav <p.raghav@xxxxxxxxxxx>
> Date:   Thu Jun 26 11:32:23 2025 +0000
> 
>     fs/buffer: remove the min and max limit checks in __getblk_slow()
> 
> 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.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux