* Re: [syzbot] [ext4?] WARNING in bdev_getblk [not found] <686a8143.a00a0220.c7b3.005b.GAE@google.com> @ 2025-07-10 9:48 ` syzbot 2025-07-11 12:27 ` syzbot 1 sibling, 0 replies; 6+ messages in thread From: syzbot @ 2025-07-10 9:48 UTC (permalink / raw) To: adilger.kernel, jfs-discussion, linkinjeon, linux-ext4, linux-fsdevel, linux-kernel, shaggy, sj1557.seo, syzkaller-bugs, tytso syzbot has found a reproducer for the following issue on: HEAD commit: 835244aba90d Add linux-next specific files for 20250709 git tree: linux-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=10535a8c580000 kernel config: https://syzkaller.appspot.com/x/.config?x=8396fd456733c122 dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=115c40f0580000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11856a8c580000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/e5c5711c47f9/disk-835244ab.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/dd2453f9f672/vmlinux-835244ab.xz kernel image: https://storage.googleapis.com/syzbot-assets/a81cc03651e7/bzImage-835244ab.xz mounted in repro: https://storage.googleapis.com/syzbot-assets/e3888e058fbc/mount_0.gz fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=12856a8c580000) IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: fs/buffer.c:1125 at __getblk_slow fs/buffer.c:1125 [inline], CPU#0: syz-executor261/5880 WARNING: fs/buffer.c:1125 at bdev_getblk+0x580/0x660 fs/buffer.c:1461, CPU#0: syz-executor261/5880 Modules linked in: CPU: 0 UID: 0 PID: 5880 Comm: syz-executor261 Not tainted 6.16.0-rc5-next-20250709-syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:__getblk_slow fs/buffer.c:1125 [inline] RIP: 0010:bdev_getblk+0x580/0x660 fs/buffer.c:1461 Code: 26 fb ff ff e8 81 ee 78 ff 48 c7 c7 20 08 9a 8b 48 c7 c6 02 1b a0 8d 4c 89 fa 4c 89 e9 e8 38 d7 e0 fe eb bd e8 61 ee 78 ff 90 <0f> 0b 90 48 b8 00 00 00 00 00 fc ff df 41 80 3c 07 00 74 08 48 89 RSP: 0018:ffffc9000403f620 EFLAGS: 00010293 RAX: ffffffff8246c6ff RBX: ffff888022d0b998 RCX: ffff888078b31e00 RDX: 0000000000000000 RSI: 0000000000000400 RDI: 0000000000000000 RBP: 0000000000000400 R08: ffff888078b31e00 R09: 0000000000000003 R10: 0000000000000406 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff888022d0b980 R14: 0000000000000400 R15: 1ffff110045a1733 FS: 000055558d712380(0000) GS:ffff888125bd4000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5b0e5d6000 CR3: 00000000227ea000 CR4: 00000000003526f0 Call Trace: <TASK> ext4_sb_breadahead_unmovable+0x6f/0xf0 fs/ext4/super.c:270 __ext4_get_inode_loc+0xcc9/0x1040 fs/ext4/inode.c:4879 __ext4_get_inode_loc_noinmem fs/ext4/inode.c:4909 [inline] __ext4_iget+0x450/0x4260 fs/ext4/inode.c:5168 __ext4_fill_super fs/ext4/super.c:5500 [inline] ext4_fill_super+0x4592/0x6080 fs/ext4/super.c:5724 get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1681 vfs_get_tree+0x8f/0x2b0 fs/super.c:1804 do_new_mount+0x2a2/0x9e0 fs/namespace.c:3805 do_mount fs/namespace.c:4133 [inline] __do_sys_mount fs/namespace.c:4344 [inline] __se_sys_mount+0x317/0x410 fs/namespace.c:4321 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f457044b7da Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 5e 04 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd924f6f58 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007ffd924f6f70 RCX: 00007f457044b7da RDX: 0000200000000040 RSI: 0000200000000000 RDI: 00007ffd924f6f70 RBP: 0000200000000000 R08: 00007ffd924f6fb0 R09: 00007ffd924f6fb0 R10: 000000000000088e R11: 0000000000000246 R12: 0000200000000040 R13: 00007ffd924f6fb0 R14: 0000000000000003 R15: 000000000000088e </TASK> --- If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [ext4?] WARNING in bdev_getblk [not found] <686a8143.a00a0220.c7b3.005b.GAE@google.com> 2025-07-10 9:48 ` [syzbot] [ext4?] WARNING in bdev_getblk syzbot @ 2025-07-11 12:27 ` syzbot 2025-07-11 15:51 ` Jan Kara 1 sibling, 1 reply; 6+ messages in thread From: syzbot @ 2025-07-11 12:27 UTC (permalink / raw) To: adilger.kernel, anna.luese, brauner, jack, jfs-discussion, libaokun1, linkinjeon, linux-ext4, linux-fsdevel, linux-kernel, p.raghav, shaggy, sj1557.seo, syzkaller-bugs, tytso syzbot has bisected this issue to: commit 77eb64439ad52d8afb57bb4dae24a2743c68f50d Author: Pankaj Raghav <p.raghav@samsung.com> 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@syzkaller.appspotmail.com 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [ext4?] WARNING in bdev_getblk 2025-07-11 12:27 ` syzbot @ 2025-07-11 15:51 ` Jan Kara 2025-07-11 16:42 ` Jan Kara 2025-07-15 10:36 ` Pankaj Raghav (Samsung) 0 siblings, 2 replies; 6+ messages in thread From: Jan Kara @ 2025-07-11 15:51 UTC (permalink / raw) To: syzbot Cc: adilger.kernel, anna.luese, brauner, jack, jfs-discussion, libaokun1, linkinjeon, linux-ext4, linux-fsdevel, linux-kernel, p.raghav, shaggy, sj1557.seo, syzkaller-bugs, tytso On Fri 11-07-25 05:27:01, syzbot wrote: > syzbot has bisected this issue to: > > commit 77eb64439ad52d8afb57bb4dae24a2743c68f50d > Author: Pankaj Raghav <p.raghav@samsung.com> > 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@syzkaller.appspotmail.com > 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@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [ext4?] WARNING in bdev_getblk 2025-07-11 15:51 ` Jan Kara @ 2025-07-11 16:42 ` Jan Kara 2025-07-11 17:30 ` syzbot 2025-07-15 10:36 ` Pankaj Raghav (Samsung) 1 sibling, 1 reply; 6+ messages in thread From: Jan Kara @ 2025-07-11 16:42 UTC (permalink / raw) To: syzbot Cc: adilger.kernel, anna.luese, brauner, jack, jfs-discussion, libaokun1, linkinjeon, linux-ext4, linux-fsdevel, linux-kernel, p.raghav, shaggy, sj1557.seo, syzkaller-bugs, tytso On Fri 11-07-25 17:51:40, Jan Kara wrote: > On Fri 11-07-25 05:27:01, syzbot wrote: > > syzbot has bisected this issue to: > > > > commit 77eb64439ad52d8afb57bb4dae24a2743c68f50d > > Author: Pankaj Raghav <p.raghav@samsung.com> > > 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@syzkaller.appspotmail.com > > 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. Sent fix here: https://lore.kernel.org/all/20250711163202.19623-2-jack@suse.cz Honza #syz test From 4aa776eb9b3967bff31087b7595ddcc902200056 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Fri, 11 Jul 2025 18:16:44 +0200 Subject: [PATCH] loop: Avoid updating block size under exclusive owner X-Developer-Signature: v=1; a=openpgp-sha256; l=3277; i=jack@suse.cz; h=from:subject; bh=cdZuEh4Dk+/Xi2fTOZRQxovM+RzBRb1FW6MBEN4Icws=; b=owGbwMvMwME4Z+4qdvsUh5uMp9WSGDIKbZq0xH0Ml+s1mUn/FXh44vuGfB7/6WemZT/fv/SJRXZ0 +Oc9nYzGLAyMHAyyYoosqyMval+bZ9S1NVRDBmYQKxPIFAYuTgGYyJE37P+TzLkNtVn5K1Q9Umaq3T Vmcb4tyOvXYsYcLfHv9g9F9zVruARylmxL8Gx73a307cwFM9/kww0b8vqYHvX33H2TnVeYsO+NW0RF KsOmd0cUjl7aWW4kFO6cOtNdIZ/HrHijk2bAKdYZ1wwucvbN27p4kRvXZfMu06WeZyz/7+FrF/9270 Ostl1ml45ORWBlp5amyvXZvl33u5tr76znST50+oRf0to8n2afbSZCK3Ris+7MjpqnMo+lK+Sf5s/+ L65hUjq2EwOyugu3PAk1khb9cHXhXN6anJo32VfsI6N+MsSzMxh+4O86wRg/98EH3obLLcIX2wOjKu es+vb1lH1Gx6ctQVE7E7Ok87oA X-Developer-Key: i=jack@suse.cz; a=openpgp; fpr=93C6099A142276A28BBE35D815BC833443038D8C Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it. Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz> --- drivers/block/loop.c | 38 ++++++++++++++++++++++++++++++-------- 1 file changed, 30 insertions(+), 8 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 500840e4a74e..5cc72770e253 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1432,17 +1432,34 @@ static int loop_set_dio(struct loop_device *lo, unsigned long arg) return 0; } -static int loop_set_block_size(struct loop_device *lo, unsigned long arg) +static int loop_set_block_size(struct loop_device *lo, blk_mode_t mode, + struct block_device *bdev, unsigned long arg) { struct queue_limits lim; unsigned int memflags; int err = 0; - if (lo->lo_state != Lo_bound) - return -ENXIO; + /* + * If we don't hold exclusive handle for the device, upgrade to it + * here to avoid changing device under exclusive owner. + */ + if (!(mode & BLK_OPEN_EXCL)) { + err = bd_prepare_to_claim(bdev, loop_set_block_size, NULL); + if (err) + return err; + } + + err = mutex_lock_killable(&lo->lo_mutex); + if (err) + goto abort_claim; + + if (lo->lo_state != Lo_bound) { + err = -ENXIO; + goto unlock; + } if (lo->lo_queue->limits.logical_block_size == arg) - return 0; + goto unlock; sync_blockdev(lo->lo_device); invalidate_bdev(lo->lo_device); @@ -1455,6 +1472,11 @@ static int loop_set_block_size(struct loop_device *lo, unsigned long arg) loop_update_dio(lo); blk_mq_unfreeze_queue(lo->lo_queue, memflags); +unlock: + mutex_unlock(&lo->lo_mutex); +abort_claim: + if (!(mode & BLK_OPEN_EXCL)) + bd_abort_claiming(bdev, loop_set_block_size); return err; } @@ -1473,9 +1495,6 @@ static int lo_simple_ioctl(struct loop_device *lo, unsigned int cmd, case LOOP_SET_DIRECT_IO: err = loop_set_dio(lo, arg); break; - case LOOP_SET_BLOCK_SIZE: - err = loop_set_block_size(lo, arg); - break; default: err = -EINVAL; } @@ -1530,9 +1549,12 @@ static int lo_ioctl(struct block_device *bdev, blk_mode_t mode, break; case LOOP_GET_STATUS64: return loop_get_status64(lo, argp); + case LOOP_SET_BLOCK_SIZE: + if (!(mode & BLK_OPEN_WRITE) && !capable(CAP_SYS_ADMIN)) + return -EPERM; + return loop_set_block_size(lo, mode, bdev, arg); case LOOP_SET_CAPACITY: case LOOP_SET_DIRECT_IO: - case LOOP_SET_BLOCK_SIZE: if (!(mode & BLK_OPEN_WRITE) && !capable(CAP_SYS_ADMIN)) return -EPERM; fallthrough; -- 2.43.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [syzbot] [ext4?] WARNING in bdev_getblk 2025-07-11 16:42 ` Jan Kara @ 2025-07-11 17:30 ` syzbot 0 siblings, 0 replies; 6+ messages in thread From: syzbot @ 2025-07-11 17:30 UTC (permalink / raw) To: adilger.kernel, anna.luese, brauner, jack, jfs-discussion, libaokun1, linkinjeon, linux-ext4, linux-fsdevel, linux-kernel, p.raghav, shaggy, sj1557.seo, syzkaller-bugs, tytso Hello, syzbot has tested the proposed patch and the reproducer did not trigger any issue: Reported-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com Tested-by: syzbot+01ef7a8da81a975e1ccd@syzkaller.appspotmail.com Tested on: commit: a62b7a37 Add linux-next specific files for 20250711 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=13b87a8c580000 kernel config: https://syzkaller.appspot.com/x/.config?x=bb4e3ec360fcbd0f dashboard link: https://syzkaller.appspot.com/bug?extid=01ef7a8da81a975e1ccd compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7 patch: https://syzkaller.appspot.com/x/patch.diff?x=14c6c68c580000 Note: testing is done by a robot and is best-effort only. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [ext4?] WARNING in bdev_getblk 2025-07-11 15:51 ` Jan Kara 2025-07-11 16:42 ` Jan Kara @ 2025-07-15 10:36 ` Pankaj Raghav (Samsung) 1 sibling, 0 replies; 6+ messages in thread From: Pankaj Raghav (Samsung) @ 2025-07-15 10:36 UTC (permalink / raw) To: Jan Kara Cc: syzbot, adilger.kernel, anna.luese, brauner, jfs-discussion, libaokun1, linkinjeon, linux-ext4, linux-fsdevel, linux-kernel, p.raghav, shaggy, sj1557.seo, syzkaller-bugs, tytso > > 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@syzkaller.appspotmail.com > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-07-15 10:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <686a8143.a00a0220.c7b3.005b.GAE@google.com>
2025-07-10 9:48 ` [syzbot] [ext4?] WARNING in bdev_getblk syzbot
2025-07-11 12:27 ` syzbot
2025-07-11 15:51 ` Jan Kara
2025-07-11 16:42 ` Jan Kara
2025-07-11 17:30 ` syzbot
2025-07-15 10:36 ` Pankaj Raghav (Samsung)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox