[PATCH] btrfs: set the block size before starting a transaction

[PATCH] btrfs: set the block size before starting a transaction

[Qing Zhang]

From: Qing Zhang <diasyzhang@tencent.com>

When adding a device, btrfs_init_new_device() calls set_blocksize()
with a transaction handle held. If the block size changes, this takes
the bdev inode's i_rwsem and triggers a lockdep dependency cycle:

  bdev i_rwsem -> mmap_lock -> trans_num_writers
              -> trans_num_extwriters -> bdev i_rwsem

The buffered read path nests mmap_lock under the bdev i_rwsem, while
mmapping a btrfs file can join a transaction through atime updates.
Since commit c0e473a0d226 ("block: fix race between set_blocksize and
read paths"), set_blocksize() takes the bdev inode's i_rwsem when
changing the block size.

Move set_blocksize() before btrfs_start_transaction() to break the
cycle. Also check its return value to reject devices whose logical
block size exceeds BTRFS_BDEV_BLOCKSIZE.

Fixes: c0e473a0d226 ("block: fix race between set_blocksize and read paths")
Reported-by: syzbot+5c01398781fb51df783a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5c01398781fb51df783a
Signed-off-by: Qing Zhang <diasyzhang@tencent.com>
---
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
 fs/btrfs/volumes.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index d3e6a9b429dd..a7f0607a5b86 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3019,6 +3019,10 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
 	if (ret)
 		goto error_free_device;
 
+	ret = set_blocksize(device->bdev_file, BTRFS_BDEV_BLOCKSIZE);
+	if (ret)
+		goto error_free_zone;
+
 	trans = btrfs_start_transaction(root, 0);
 	if (IS_ERR(trans)) {
 		ret = PTR_ERR(trans);
@@ -3043,7 +3047,6 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
 	 */
 	atomic_inc(&device->dev_stats_ccnt);
 	device->dev_stats_valid = 1;
-	set_blocksize(device->bdev_file, BTRFS_BDEV_BLOCKSIZE);
 
 	if (seeding_dev) {
 		/* GFP_KERNEL allocation must not be under device_list_mutex */
-- 
2.43.7

Re: [syzbot] [btrfs?] possible deadlock in set_blocksize

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in __btrfs_free_extent

------------[ cut here ]------------
ret == -E
ret == -ENOENT
WARNING: fs/btrfs/extent-tree.c:3418 at __btrfs_free_extent+0x1745/0x38a0 fs/btrfs/extent-tree.c:3418, CPU#1: btrfs-transacti/6038
Modules linked in:
CPU: 1 UID: 0 PID: 6038 Comm: btrfs-transacti Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/15/2026
RIP: 0010:__btrfs_free_extent+0x1745/0x38a0 fs/btrfs/extent-tree.c:3418
Code: 84 c0 0f 84 01 03 00 00 e8 d8 88 a8 fd e9 30 0b 00 00 e8 1e ef 8c fd 84 c0 0f 84 0c 03 00 00 e8 c1 88 a8 fd e9 9d 0c 00 00 90 <0f> 0b 90 48 8b 44 24 28 42 80 3c 20 00 4d 8d 75 60 74 08 4c 89 f7
RSP: 0018:ffffc900034d7580 EFLAGS: 00010246
RAX: 00000000fffffffe RBX: ffff88801faee720 RCX: 0000000000000005
RDX: ffffffff8420790e RSI: ffffffff905d9c00 RDI: 00000000fffffffe
RBP: ffffc900034d7730 R08: ffff888021381f40 R09: 0000000000000002
R10: 00000000fffffffe R11: 0000000000000000 R12: dffffc0000000000
R13: ffff88805ad54178 R14: ffff888053e7ddc0 R15: 00000000fffffffe
FS:  0000000000000000(0000) GS:ffff88812372b000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000560567923d51 CR3: 000000007caed000 CR4: 0000000000350ef0
Call Trace:
 <TASK>
 run_delayed_tree_ref fs/btrfs/extent-tree.c:1824 [inline]
 run_one_delayed_ref fs/btrfs/extent-tree.c:1851 [inline]
 btrfs_run_delayed_refs_for_head fs/btrfs/extent-tree.c:2058 [inline]
 __btrfs_run_delayed_refs+0x1669/0x43a0 fs/btrfs/extent-tree.c:2134
 btrfs_run_delayed_refs+0xdc/0x2a0 fs/btrfs/extent-tree.c:2246
 btrfs_commit_transaction+0x287/0x3010 fs/btrfs/transaction.c:2283
 transaction_kthread+0x2c1/0x460 fs/btrfs/disk-io.c:1586
 kthread+0x38b/0x480 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>


Tested on:

commit:         65ba8f34 Merge tag 'xtensa-20261027' of https://github..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1439e469580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=fbcd9c8641bd149b
dashboard link: https://syzkaller.appspot.com/bug?extid=5c01398781fb51df783a
compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
patch:          https://syzkaller.appspot.com/x/patch.diff?x=11607721580000

Re: [PATCH] btrfs: set the block size before starting a transaction

[Qu Wenruo]

在 2026/10/28 22:44, Qing Zhang 写道:
> From: Qing Zhang <diasyzhang@tencent.com>
> 
> When adding a device, btrfs_init_new_device() calls set_blocksize()
> with a transaction handle held. If the block size changes, this takes
> the bdev inode's i_rwsem and triggers a lockdep dependency cycle:
> 
>    bdev i_rwsem -> mmap_lock -> trans_num_writers
>                -> trans_num_extwriters -> bdev i_rwsem
> 
> The buffered read path nests mmap_lock under the bdev i_rwsem, while
> mmapping a btrfs file can join a transaction through atime updates.
> Since commit c0e473a0d226 ("block: fix race between set_blocksize and
> read paths"), set_blocksize() takes the bdev inode's i_rwsem when
> changing the block size.
> 
> Move set_blocksize() before btrfs_start_transaction() to break the
> cycle. Also check its return value to reject devices whose logical
> block size exceeds BTRFS_BDEV_BLOCKSIZE.
> 
> Fixes: c0e473a0d226 ("block: fix race between set_blocksize and read paths")
> Reported-by: syzbot+5c01398781fb51df783a@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=5c01398781fb51df783a

There is already a better solution by not calling the stupid 
ste_blocksize() at all:

https://lore.kernel.org/linux-btrfs/3d98566e8aa2cd99a23ce89665f79281c614f05e.1792885061.git.wqu@suse.com/


> Signed-off-by: Qing Zhang <diasyzhang@tencent.com>
> ---
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>   fs/btrfs/volumes.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index d3e6a9b429dd..a7f0607a5b86 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -3019,6 +3019,10 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
>   	if (ret)
>   		goto error_free_device;
>   
> +	ret = set_blocksize(device->bdev_file, BTRFS_BDEV_BLOCKSIZE);
> +	if (ret)
> +		goto error_free_zone;
> +
>   	trans = btrfs_start_transaction(root, 0);
>   	if (IS_ERR(trans)) {
>   		ret = PTR_ERR(trans);
> @@ -3043,7 +3047,6 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
>   	 */
>   	atomic_inc(&device->dev_stats_ccnt);
>   	device->dev_stats_valid = 1;
> -	set_blocksize(device->bdev_file, BTRFS_BDEV_BLOCKSIZE);
>   
>   	if (seeding_dev) {
>   		/* GFP_KERNEL allocation must not be under device_list_mutex */

[syzbot] [btrfs?] possible deadlock in set_blocksize

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    4169c9c90532 powerpc/irq: Fix build with CONFIG_PROC_FS=n
git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=14fdcbcd580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e397d1e24d3cb03
dashboard link: https://syzkaller.appspot.com/bug?extid=5c01398781fb51df783a
compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=132c1a31580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5c01398781fb51df783a@syzkaller.appspotmail.com

======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz-executor324/6058 is trying to acquire lock:
ffff888024d4e3e8 (&sb->s_type->i_mutex_key#10){++++}-{4:4}, at: inode_lock include/linux/fs.h:1024 [inline]
ffff888024d4e3e8 (&sb->s_type->i_mutex_key#10){++++}-{4:4}, at: set_blocksize+0x1e6/0x440 block/bdev.c:202

but task is already holding lock:
ffff888027eb26a8 (btrfs_trans_num_extwriters){.+.+}-{0:0}, at: join_transaction+0x6b2/0xd40 fs/btrfs/transaction.c:331

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #3 (btrfs_trans_num_extwriters){.+.+}-{0:0}:
       join_transaction+0x18a/0xd40 fs/btrfs/transaction.c:356
       start_transaction+0x731/0x1830 fs/btrfs/transaction.c:770
       btrfs_create_common+0x15c/0x310 fs/btrfs/inode.c:6991
       lookup_open+0xedc/0x1970 fs/namei.c:4569
       open_last_lookups fs/namei.c:4768 [inline]
       path_openat+0x70c/0x20f0 fs/namei.c:5007
       do_file_open+0x23e/0x4a0 fs/namei.c:5039
       do_sys_openat2+0x115/0x200 fs/open.c:1442
       do_sys_open fs/open.c:1448 [inline]
       __do_sys_openat fs/open.c:1464 [inline]
       __se_sys_openat fs/open.c:1459 [inline]
       __x64_sys_openat+0x138/0x170 fs/open.c:1459
       do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
       do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #2 (btrfs_trans_num_writers){.+.+}-{0:0}:
       __lock_release kernel/locking/lockdep.c:5627 [inline]
       lock_release+0x1a3/0x3c0 kernel/locking/lockdep.c:5964
       percpu_up_read include/linux/percpu-rwsem.h:114 [inline]
       __sb_end_write include/linux/fs/super.h:14 [inline]
       sb_end_intwrite+0x26/0x190 include/linux/fs/super.h:101
       __btrfs_end_transaction+0x237/0x640 fs/btrfs/transaction.c:1147
       btrfs_dirty_inode+0x14c/0x190 fs/btrfs/inode.c:6444
       touch_atime+0x2f8/0x670 fs/inode.c:2325
       file_accessed include/linux/fs.h:2279 [inline]
       btrfs_file_mmap_prepare+0x172/0x1f0 fs/btrfs/file.c:2003
       vfs_mmap_prepare include/linux/fs.h:2071 [inline]
       call_mmap_prepare mm/vma.c:2815 [inline]
       __mmap_region mm/vma.c:2913 [inline]
       mmap_region+0xe88/0x23c0 mm/vma.c:3014
       do_mmap+0xe0a/0x1300 mm/mmap.c:573
       vm_mmap_pgoff+0x272/0x4e0 mm/util.c:581
       ksys_mmap_pgoff+0x4dc/0x760 mm/mmap.c:619
       do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
       do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #1 (&mm->mmap_lock){++++}-{4:4}:
       __might_fault+0xcb/0x130 mm/memory.c:7419
       _copy_to_iter+0xf9/0x1810 lib/iov_iter.c:196
       copy_page_to_iter+0x23f/0x330 lib/iov_iter.c:374
       copy_folio_to_iter include/linux/uio.h:204 [inline]
       filemap_read+0x7af/0x11e0 mm/filemap.c:2893
       blkdev_read_iter+0x2f1/0x420 block/fops.c:838
       new_sync_read fs/read_write.c:493 [inline]
       vfs_read+0x595/0xa80 fs/read_write.c:574
       ksys_read+0x150/0x270 fs/read_write.c:716
       do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
       do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #0 (&sb->s_type->i_mutex_key#10){++++}-{4:4}:
       check_prev_add kernel/locking/lockdep.c:3209 [inline]
       check_prevs_add kernel/locking/lockdep.c:3328 [inline]
       validate_chain kernel/locking/lockdep.c:3952 [inline]
       __lock_acquire+0x164c/0x2de0 kernel/locking/lockdep.c:5288
       lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5942
       down_write+0x91/0x200 kernel/locking/rwsem.c:1631
       inode_lock include/linux/fs.h:1024 [inline]
       set_blocksize+0x1e6/0x440 block/bdev.c:202
       btrfs_init_new_device+0xa4e/0x1cf0 fs/btrfs/volumes.c:3046
       btrfs_ioctl_add_dev+0x1ad/0x640 fs/btrfs/ioctl.c:2571
       vfs_ioctl fs/ioctl.c:51 [inline]
       __do_sys_ioctl fs/ioctl.c:597 [inline]
       __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
       do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
       do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

Chain exists of:
  &sb->s_type->i_mutex_key#10 --> btrfs_trans_num_writers --> btrfs_trans_num_extwriters

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  rlock(btrfs_trans_num_extwriters);
                               lock(btrfs_trans_num_writers);
                               lock(btrfs_trans_num_extwriters);
  lock(&sb->s_type->i_mutex_key#10);

 *** DEADLOCK ***

locks held by syz-executor324/6058: 3, last CPU#0:
 #0: ffff8880139a2650 (sb_internal#2){.+.+}-{0:0}, at: btrfs_init_new_device+0x7f3/0x1cf0 fs/btrfs/volumes.c:3022
 #1: ffff888027eb2680 (btrfs_trans_num_writers){.+.+}-{0:0}, at: join_transaction+0x6b2/0xd40 fs/btrfs/transaction.c:331
 #2: ffff888027eb26a8 (btrfs_trans_num_extwriters){.+.+}-{0:0}, at: join_transaction+0x6b2/0xd40 fs/btrfs/transaction.c:331

stack backtrace:
CPU: 0 UID: 0 PID: 6058 Comm: syz-executor324 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/15/2026
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_circular_bug+0x2e2/0x300 kernel/locking/lockdep.c:2087
 check_noncircular+0x12f/0x150 kernel/locking/lockdep.c:2219
 check_prev_add kernel/locking/lockdep.c:3209 [inline]
 check_prevs_add kernel/locking/lockdep.c:3328 [inline]
 validate_chain kernel/locking/lockdep.c:3952 [inline]
 __lock_acquire+0x164c/0x2de0 kernel/locking/lockdep.c:5288
 lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5942
 down_write+0x91/0x200 kernel/locking/rwsem.c:1631
 inode_lock include/linux/fs.h:1024 [inline]
 set_blocksize+0x1e6/0x440 block/bdev.c:202
 btrfs_init_new_device+0xa4e/0x1cf0 fs/btrfs/volumes.c:3046
 btrfs_ioctl_add_dev+0x1ad/0x640 fs/btrfs/ioctl.c:2571
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:597 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8612ea2ebb
Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
RSP: 002b:00007ffe693cf9a0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8612ea2ebb
RDX: 00007ffe693d2bf0 RSI: 000000005000940a RDI: 0000000000000003
RBP: 00007ffe693d2bf0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe693cfb20
R13: 0000000000000000 R14: 00007f8612e71000 R15: 00007ffe693cff70
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

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.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup