[syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree

[syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    5d4809e25903 Add linux-next specific files for 20250620
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1421b370580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=58afc4b78b52b7e3
dashboard link: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11f1cb0c580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14aff30c580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/16492bf6b788/disk-5d4809e2.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7be284ded1de/vmlinux-5d4809e2.xz
kernel image: https://storage.googleapis.com/syzbot-assets/467d717f0d9c/bzImage-5d4809e2.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/4a74fbfa0b0f/mount_0.gz
  fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1030cdd4580000)

The issue was bisected to:

commit 7aacdf6feed1ca882339ebd3895a233373b40a1e
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jun 17 05:19:38 2025 +0000

    btrfs: delay btrfs_open_devices() until super block is created

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=14d29b0c580000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=16d29b0c580000
console output: https://syzkaller.appspot.com/x/log.txt?x=12d29b0c580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
Fixes: 7aacdf6feed1 ("btrfs: delay btrfs_open_devices() until super block is created")

BTRFS info (device loop0): using sha256 (sha256-x86_64) checksum algorithm
BTRFS info (device loop0): disk space caching is enabled
BTRFS warning (device loop0): space cache v1 is being deprecated and will be removed in a future release, please use -o space_cache=v2
======================================================
WARNING: possible circular locking dependency detected
6.16.0-rc2-next-20250620-syzkaller #0 Not tainted
------------------------------------------------------
syz-executor123/5843 is trying to acquire lock:
ffffffff8e6e9fe8 (uuid_mutex){+.+.}-{4:4}, at: btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462

but task is already holding lock:
ffff8880328ea0e0 (&type->s_umount_key#41/1){+.+.}-{4:4}, at: alloc_super+0x204/0x970 fs/super.c:345

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
       lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
       down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
       alloc_super+0x204/0x970 fs/super.c:345
       sget_fc+0x329/0xa40 fs/super.c:761
       btrfs_get_tree_super fs/btrfs/super.c:1867 [inline]
       btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
       btrfs_get_tree+0x4c6/0x12d0 fs/btrfs/super.c:2093
       vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
       do_new_mount+0x24a/0xa40 fs/namespace.c:3902
       do_mount fs/namespace.c:4239 [inline]
       __do_sys_mount fs/namespace.c:4450 [inline]
       __se_sys_mount+0x317/0x410 fs/namespace.c:4427
       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

-> #0 (uuid_mutex){+.+.}-{4:4}:
       check_prev_add kernel/locking/lockdep.c:3168 [inline]
       check_prevs_add kernel/locking/lockdep.c:3287 [inline]
       validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
       __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
       lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
       __mutex_lock_common kernel/locking/mutex.c:602 [inline]
       __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
       btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
       open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
       btrfs_fill_super fs/btrfs/super.c:984 [inline]
       btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
       btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
       btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
       vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
       do_new_mount+0x24a/0xa40 fs/namespace.c:3902
       do_mount fs/namespace.c:4239 [inline]
       __do_sys_mount fs/namespace.c:4450 [inline]
       __se_sys_mount+0x317/0x410 fs/namespace.c:4427
       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

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&type->s_umount_key#41/1);
                               lock(uuid_mutex);
                               lock(&type->s_umount_key#41/1);
  lock(uuid_mutex);

 *** DEADLOCK ***

1 lock held by syz-executor123/5843:
 #0: ffff8880328ea0e0 (&type->s_umount_key#41/1){+.+.}-{4:4}, at: alloc_super+0x204/0x970 fs/super.c:345

stack backtrace:
CPU: 1 UID: 0 PID: 5843 Comm: syz-executor123 Not tainted 6.16.0-rc2-next-20250620-syzkaller #0 PREEMPT(full) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
 <TASK>
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2046
 check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2178
 check_prev_add kernel/locking/lockdep.c:3168 [inline]
 check_prevs_add kernel/locking/lockdep.c:3287 [inline]
 validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
 __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
 __mutex_lock_common kernel/locking/mutex.c:602 [inline]
 __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
 btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
 open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
 btrfs_fill_super fs/btrfs/super.c:984 [inline]
 btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
 btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
 btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
 vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
 do_new_mount+0x24a/0xa40 fs/namespace.c:3902
 do_mount fs/namespace.c:4239 [inline]
 __do_sys_mount fs/namespace.c:4450 [inline]
 __se_sys_mount+0x317/0x410 fs/namespace.c:4427
 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:0x7fda63124f3a
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:00007ffd76f19cb8 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffd76f19cd0 RCX: 00007fda63124f3a
RDX: 00002000000004c0 RSI: 00002000000015c0 RDI: 00007ffd76f19cd0
RBP: 00002000000004c0 R08: 00007ffd76f19d10 R09: 0000000000005598
R10: 0000000002000000 R11: 0000000000000282 R12: 00002000000015c0
R13: 00007ffd76f19d10 R14: 0000000000000003 R15: 0000000002000000
 </TASK>
BTRFS info (device loop0): rebuilding free space tree
BTRFS info (device loop0): disabling free space tree
BTRFS info (device loop0): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)
BTRFS info (device loop0): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)


---
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.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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

[PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Edward Adam Davis]

Remove the lock uuid_mutex outside of sget_fc() to avoid the deadlock
reported by [1].

[1]
-> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
       lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
       down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
       alloc_super+0x204/0x970 fs/super.c:345
       sget_fc+0x329/0xa40 fs/super.c:761
       btrfs_get_tree_super fs/btrfs/super.c:1867 [inline]
       btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
       btrfs_get_tree+0x4c6/0x12d0 fs/btrfs/super.c:2093
       vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
       do_new_mount+0x24a/0xa40 fs/namespace.c:3902
       do_mount fs/namespace.c:4239 [inline]
       __do_sys_mount fs/namespace.c:4450 [inline]
       __se_sys_mount+0x317/0x410 fs/namespace.c:4427
       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

-> #0 (uuid_mutex){+.+.}-{4:4}:
       check_prev_add kernel/locking/lockdep.c:3168 [inline]
       check_prevs_add kernel/locking/lockdep.c:3287 [inline]
       validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
       __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
       lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
       __mutex_lock_common kernel/locking/mutex.c:602 [inline]
       __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
       btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
       open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
       btrfs_fill_super fs/btrfs/super.c:984 [inline]
       btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
       btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
       btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
       vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
       do_new_mount+0x24a/0xa40 fs/namespace.c:3902
       do_mount fs/namespace.c:4239 [inline]
       __do_sys_mount fs/namespace.c:4450 [inline]
       __se_sys_mount+0x317/0x410 fs/namespace.c:4427
       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

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&type->s_umount_key#41/1);
                               lock(uuid_mutex);
                               lock(&type->s_umount_key#41/1);
  lock(uuid_mutex);

 *** DEADLOCK ***

Fixes: 7aacdf6feed1 ("btrfs: delay btrfs_open_devices() until super block is created")
Reported-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
Tested-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 fs/btrfs/super.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 237e60b53192..c2ce1eb53ad7 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1864,11 +1864,10 @@ static int btrfs_get_tree_super(struct fs_context *fc)
 	fs_devices = device->fs_devices;
 	fs_info->fs_devices = fs_devices;
 
+	mutex_unlock(&uuid_mutex);
 	sb = sget_fc(fc, btrfs_fc_test_super, set_anon_super_fc);
-	if (IS_ERR(sb)) {
-		mutex_unlock(&uuid_mutex);
+	if (IS_ERR(sb))
 		return PTR_ERR(sb);
-	}
 
 	set_device_specific_options(fs_info);
 
@@ -1887,6 +1886,7 @@ static int btrfs_get_tree_super(struct fs_context *fc)
 		 * But the fs_info->fs_devices is not opened, we should not let
 		 * btrfs_free_fs_context() to close them.
 		 */
+		mutex_lock(&uuid_mutex);
 		fs_info->fs_devices = NULL;
 		mutex_unlock(&uuid_mutex);
 
@@ -1906,6 +1906,7 @@ static int btrfs_get_tree_super(struct fs_context *fc)
 		 */
 		ASSERT(fc->s_fs_info == NULL);
 
+		mutex_lock(&uuid_mutex);
 		ret = btrfs_open_devices(fs_devices, mode, sb);
 		mutex_unlock(&uuid_mutex);
 		if (ret < 0) {
-- 
2.43.0

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Qu Wenruo]

在 2025/6/25 00:00, Edward Adam Davis 写道:
> Remove the lock uuid_mutex outside of sget_fc() to avoid the deadlock
> reported by [1].
> 
> [1]
> -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
>         lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>         down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
>         alloc_super+0x204/0x970 fs/super.c:345
>         sget_fc+0x329/0xa40 fs/super.c:761
>         btrfs_get_tree_super fs/btrfs/super.c:1867 [inline]
>         btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
>         btrfs_get_tree+0x4c6/0x12d0 fs/btrfs/super.c:2093
>         vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
>         do_new_mount+0x24a/0xa40 fs/namespace.c:3902
>         do_mount fs/namespace.c:4239 [inline]
>         __do_sys_mount fs/namespace.c:4450 [inline]
>         __se_sys_mount+0x317/0x410 fs/namespace.c:4427
>         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
> 
> -> #0 (uuid_mutex){+.+.}-{4:4}:
>         check_prev_add kernel/locking/lockdep.c:3168 [inline]
>         check_prevs_add kernel/locking/lockdep.c:3287 [inline]
>         validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
>         __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
>         lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>         __mutex_lock_common kernel/locking/mutex.c:602 [inline]
>         __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
>         btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
>         open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
>         btrfs_fill_super fs/btrfs/super.c:984 [inline]
>         btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
>         btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
>         btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
>         vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
>         do_new_mount+0x24a/0xa40 fs/namespace.c:3902
>         do_mount fs/namespace.c:4239 [inline]
>         __do_sys_mount fs/namespace.c:4450 [inline]
>         __se_sys_mount+0x317/0x410 fs/namespace.c:4427
>         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
> 
> other info that might help us debug this:
> 
>   Possible unsafe locking scenario:
> 
>         CPU0                    CPU1
>         ----                    ----
>    lock(&type->s_umount_key#41/1);
>                                 lock(uuid_mutex);
>                                 lock(&type->s_umount_key#41/1);
>    lock(uuid_mutex);
> 
>   *** DEADLOCK ***
> 
> Fixes: 7aacdf6feed1 ("btrfs: delay btrfs_open_devices() until super block is created")
> Reported-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
> Tested-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>   fs/btrfs/super.c | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 237e60b53192..c2ce1eb53ad7 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -1864,11 +1864,10 @@ static int btrfs_get_tree_super(struct fs_context *fc)
>   	fs_devices = device->fs_devices;
>   	fs_info->fs_devices = fs_devices;
>   
> +	mutex_unlock(&uuid_mutex);

No, you can not unlock uuid_mutex without opening the devices.

Just run the test case generic/604.

>   	sb = sget_fc(fc, btrfs_fc_test_super, set_anon_super_fc);
> -	if (IS_ERR(sb)) {
> -		mutex_unlock(&uuid_mutex);
> +	if (IS_ERR(sb))
>   		return PTR_ERR(sb);
> -	}
>   
>   	set_device_specific_options(fs_info);
>   
> @@ -1887,6 +1886,7 @@ static int btrfs_get_tree_super(struct fs_context *fc)
>   		 * But the fs_info->fs_devices is not opened, we should not let
>   		 * btrfs_free_fs_context() to close them.
>   		 */
> +		mutex_lock(&uuid_mutex);
>   		fs_info->fs_devices = NULL;
>   		mutex_unlock(&uuid_mutex);
>   
> @@ -1906,6 +1906,7 @@ static int btrfs_get_tree_super(struct fs_context *fc)
>   		 */
>   		ASSERT(fc->s_fs_info == NULL);
>   
> +		mutex_lock(&uuid_mutex);
>   		ret = btrfs_open_devices(fs_devices, mode, sb);
>   		mutex_unlock(&uuid_mutex);
>   		if (ret < 0) {

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Hillf Danton]

On Wed, 25 Jun 2025 06:00:09 +0930 Qu Wenruo wrote:
> =E5=9C=A8 2025/6/25 00:00, Edward Adam Davis =E5=86=99=E9=81=93:
> > Remove the lock uuid_mutex outside of sget_fc() to avoid the deadlock
> > reported by [1].
> >=20
> > [1]
> > -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
> >         lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
> >         down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
> >         alloc_super+0x204/0x970 fs/super.c:345

Given kzalloc [3], the syzbot report is false positive (a known lockdep
issue) as nobody else should acquire s->s_umount lock.

[3] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/super.c?id=7aacdf6feed1#n319

> >         sget_fc+0x329/0xa40 fs/super.c:761
> >         btrfs_get_tree_super fs/btrfs/super.c:1867 [inline]
> >         btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
> >         btrfs_get_tree+0x4c6/0x12d0 fs/btrfs/super.c:2093
> >         vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
> >         do_new_mount+0x24a/0xa40 fs/namespace.c:3902
> >         do_mount fs/namespace.c:4239 [inline]
> >         __do_sys_mount fs/namespace.c:4450 [inline]
> >         __se_sys_mount+0x317/0x410 fs/namespace.c:4427
> >         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
> >=20
> > -> #0 (uuid_mutex){+.+.}-{4:4}:
> >         check_prev_add kernel/locking/lockdep.c:3168 [inline]
> >         check_prevs_add kernel/locking/lockdep.c:3287 [inline]
> >         validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
> >         __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
> >         lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
> >         __mutex_lock_common kernel/locking/mutex.c:602 [inline]
> >         __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
> >         btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
> >         open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
> >         btrfs_fill_super fs/btrfs/super.c:984 [inline]
> >         btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
> >         btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
> >         btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
> >         vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
> >         do_new_mount+0x24a/0xa40 fs/namespace.c:3902
> >         do_mount fs/namespace.c:4239 [inline]
> >         __do_sys_mount fs/namespace.c:4450 [inline]
> >         __se_sys_mount+0x317/0x410 fs/namespace.c:4427
> >         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
> >=20
> > other info that might help us debug this:
> >=20
> >   Possible unsafe locking scenario:
> >=20
> >         CPU0                    CPU1
> >         ----                    ----
> >    lock(&type->s_umount_key#41/1);
> >                                 lock(uuid_mutex);
> >                                 lock(&type->s_umount_key#41/1);
> >    lock(uuid_mutex);
> >=20
> >   *** DEADLOCK ***
> >=20
> > Fixes: 7aacdf6feed1 ("btrfs: delay btrfs_open_devices() until super bloc=
> k is created")
> > Reported-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=3Dfa90fcaa28f5cd4b1fc1
> > Tested-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> >   fs/btrfs/super.c | 7 ++++---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> >=20
> > diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> > index 237e60b53192..c2ce1eb53ad7 100644
> > --- a/fs/btrfs/super.c
> > +++ b/fs/btrfs/super.c
> > @@ -1864,11 +1864,10 @@ static int btrfs_get_tree_super(struct fs_contex=
> t *fc)
> >   	fs_devices =3D device->fs_devices;
> >   	fs_info->fs_devices =3D fs_devices;
> >  =20
> > +	mutex_unlock(&uuid_mutex);
> 
> No, you can not unlock uuid_mutex without opening the devices.
> 
> Just run the test case generic/604.
> 
> >   	sb =3D sget_fc(fc, btrfs_fc_test_super, set_anon_super_fc);
> > -	if (IS_ERR(sb)) {
> > -		mutex_unlock(&uuid_mutex);
> > +	if (IS_ERR(sb))
> >   		return PTR_ERR(sb);
> > -	}
> >  =20
> >   	set_device_specific_options(fs_info);
> >  =20
> > @@ -1887,6 +1886,7 @@ static int btrfs_get_tree_super(struct fs_context =
> *fc)
> >   		 * But the fs_info->fs_devices is not opened, we should not let
> >   		 * btrfs_free_fs_context() to close them.
> >   		 */
> > +		mutex_lock(&uuid_mutex);
> >   		fs_info->fs_devices =3D NULL;
> >   		mutex_unlock(&uuid_mutex);
> >  =20
> > @@ -1906,6 +1906,7 @@ static int btrfs_get_tree_super(struct fs_context =
> *fc)
> >   		 */
> >   		ASSERT(fc->s_fs_info =3D=3D NULL);
> >  =20
> > +		mutex_lock(&uuid_mutex);
> >   		ret =3D btrfs_open_devices(fs_devices, mode, sb);
> >   		mutex_unlock(&uuid_mutex);
> >   		if (ret < 0) {

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Qu Wenruo]

在 2025/6/25 09:26, Hillf Danton 写道:
> On Wed, 25 Jun 2025 06:00:09 +0930 Qu Wenruo wrote:
>> =E5=9C=A8 2025/6/25 00:00, Edward Adam Davis =E5=86=99=E9=81=93:
>>> Remove the lock uuid_mutex outside of sget_fc() to avoid the deadlock
>>> reported by [1].
>>> =20
>>> [1]
>>> -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
>>>          lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>>>          down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
>>>          alloc_super+0x204/0x970 fs/super.c:345
> 
> Given kzalloc [3], the syzbot report is false positive (a known lockdep
> issue) as nobody else should acquire s->s_umount lock.
> 
> [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/super.c?id=7aacdf6feed1#n319

Not a false alert either.

sget_fc() can return an existing super block, we can race between a 
mount and an unmount on the same super block.

In that case it's going to cause problem.

This is already fixed in the v4 (and later v5) patchset:

https://lore.kernel.org/linux-btrfs/cover.1750724841.git.wqu@suse.com/

Thanks,
Qu

> 
>>>          sget_fc+0x329/0xa40 fs/super.c:761
>>>          btrfs_get_tree_super fs/btrfs/super.c:1867 [inline]
>>>          btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
>>>          btrfs_get_tree+0x4c6/0x12d0 fs/btrfs/super.c:2093
>>>          vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
>>>          do_new_mount+0x24a/0xa40 fs/namespace.c:3902
>>>          do_mount fs/namespace.c:4239 [inline]
>>>          __do_sys_mount fs/namespace.c:4450 [inline]
>>>          __se_sys_mount+0x317/0x410 fs/namespace.c:4427
>>>          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
>>> =20
>>> -> #0 (uuid_mutex){+.+.}-{4:4}:
>>>          check_prev_add kernel/locking/lockdep.c:3168 [inline]
>>>          check_prevs_add kernel/locking/lockdep.c:3287 [inline]
>>>          validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
>>>          __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
>>>          lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>>>          __mutex_lock_common kernel/locking/mutex.c:602 [inline]
>>>          __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
>>>          btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
>>>          open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
>>>          btrfs_fill_super fs/btrfs/super.c:984 [inline]
>>>          btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
>>>          btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
>>>          btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
>>>          vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
>>>          do_new_mount+0x24a/0xa40 fs/namespace.c:3902
>>>          do_mount fs/namespace.c:4239 [inline]
>>>          __do_sys_mount fs/namespace.c:4450 [inline]
>>>          __se_sys_mount+0x317/0x410 fs/namespace.c:4427
>>>          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
>>> =20
>>> other info that might help us debug this:
>>> =20
>>>    Possible unsafe locking scenario:
>>> =20
>>>          CPU0                    CPU1
>>>          ----                    ----
>>>     lock(&type->s_umount_key#41/1);
>>>                                  lock(uuid_mutex);
>>>                                  lock(&type->s_umount_key#41/1);
>>>     lock(uuid_mutex);
>>> =20
>>>    *** DEADLOCK ***
>>> =20
>>> Fixes: 7aacdf6feed1 ("btrfs: delay btrfs_open_devices() until super bloc=
>> k is created")
>>> Reported-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
>>> Closes: https://syzkaller.appspot.com/bug?extid=3Dfa90fcaa28f5cd4b1fc1
>>> Tested-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
>>> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
>>> ---
>>>    fs/btrfs/super.c | 7 ++++---
>>>    1 file changed, 4 insertions(+), 3 deletions(-)
>>> =20
>>> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
>>> index 237e60b53192..c2ce1eb53ad7 100644
>>> --- a/fs/btrfs/super.c
>>> +++ b/fs/btrfs/super.c
>>> @@ -1864,11 +1864,10 @@ static int btrfs_get_tree_super(struct fs_contex=
>> t *fc)
>>>    	fs_devices =3D device->fs_devices;
>>>    	fs_info->fs_devices =3D fs_devices;
>>>   =20
>>> +	mutex_unlock(&uuid_mutex);
>>
>> No, you can not unlock uuid_mutex without opening the devices.
>>
>> Just run the test case generic/604.
>>
>>>    	sb =3D sget_fc(fc, btrfs_fc_test_super, set_anon_super_fc);
>>> -	if (IS_ERR(sb)) {
>>> -		mutex_unlock(&uuid_mutex);
>>> +	if (IS_ERR(sb))
>>>    		return PTR_ERR(sb);
>>> -	}
>>>   =20
>>>    	set_device_specific_options(fs_info);
>>>   =20
>>> @@ -1887,6 +1886,7 @@ static int btrfs_get_tree_super(struct fs_context =
>> *fc)
>>>    		 * But the fs_info->fs_devices is not opened, we should not let
>>>    		 * btrfs_free_fs_context() to close them.
>>>    		 */
>>> +		mutex_lock(&uuid_mutex);
>>>    		fs_info->fs_devices =3D NULL;
>>>    		mutex_unlock(&uuid_mutex);
>>>   =20
>>> @@ -1906,6 +1906,7 @@ static int btrfs_get_tree_super(struct fs_context =
>> *fc)
>>>    		 */
>>>    		ASSERT(fc->s_fs_info =3D=3D NULL);
>>>   =20
>>> +		mutex_lock(&uuid_mutex);
>>>    		ret =3D btrfs_open_devices(fs_devices, mode, sb);
>>>    		mutex_unlock(&uuid_mutex);
>>>    		if (ret < 0) {
> 

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Hillf Danton]

On Wed, 25 Jun 2025 20:19:06 +0930 Qu Wenruo wrote:
> =E5=9C=A8 2025/6/25 09:26, Hillf Danton =E5=86=99=E9=81=93:
> > On Wed, 25 Jun 2025 06:00:09 +0930 Qu Wenruo wrote:
> >> =3DE5=3D9C=3DA8 2025/6/25 00:00, Edward Adam Davis =3DE5=3D86=3D99=3DE9=
> =3D81=3D93:
> >>> Remove the lock uuid_mutex outside of sget_fc() to avoid the deadlock
> >>> reported by [1].
> >>> =3D20
> >>> [1]
> >>> -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
> >>>          lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
> >>>          down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
> >>>          alloc_super+0x204/0x970 fs/super.c:345
> >=20
> > Given kzalloc [3], the syzbot report is false positive (a known lockdep
> > issue) as nobody else should acquire s->s_umount lock.
> >=20
> > [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.=
> git/tree/fs/super.c?id=3D7aacdf6feed1#n319
> 
> Not a false alert either.
> 
> sget_fc() can return an existing super block, we can race between a=20
> mount and an unmount on the same super block.
> 
> In that case it's going to cause problem.
> 
> This is already fixed in the v4 (and later v5) patchset:
> 
> https://lore.kernel.org/linux-btrfs/cover.1750724841.git.wqu@suse.com/
> 
Can v5 survive the syzbot test?

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Qu Wenruo]

在 2025/6/25 22:10, Hillf Danton 写道:
> On Wed, 25 Jun 2025 20:19:06 +0930 Qu Wenruo wrote:
>> =E5=9C=A8 2025/6/25 09:26, Hillf Danton =E5=86=99=E9=81=93:
>>> On Wed, 25 Jun 2025 06:00:09 +0930 Qu Wenruo wrote:
>>>> =3DE5=3D9C=3DA8 2025/6/25 00:00, Edward Adam Davis =3DE5=3D86=3D99=3DE9=
>> =3D81=3D93:
>>>>> Remove the lock uuid_mutex outside of sget_fc() to avoid the deadlock
>>>>> reported by [1].
>>>>> =3D20
>>>>> [1]
>>>>> -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
>>>>>           lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>>>>>           down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
>>>>>           alloc_super+0x204/0x970 fs/super.c:345
>>> =20
>>> Given kzalloc [3], the syzbot report is false positive (a known lockdep
>>> issue) as nobody else should acquire s->s_umount lock.
>>> =20
>>> [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.=
>> git/tree/fs/super.c?id=3D7aacdf6feed1#n319
>>
>> Not a false alert either.
>>
>> sget_fc() can return an existing super block, we can race between a=20
>> mount and an unmount on the same super block.
>>
>> In that case it's going to cause problem.
>>
>> This is already fixed in the v4 (and later v5) patchset:
>>
>> https://lore.kernel.org/linux-btrfs/cover.1750724841.git.wqu@suse.com/
>>
> Can v5 survive the syzbot test?

Yes, I enabled lockdep during v5 tests.

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Hillf Danton]

On Thu, 26 Jun 2025 06:59:14 +0930 Qu Wenruo wrote:
> =E5=9C=A8 2025/6/25 22:10, Hillf Danton =E5=86=99=E9=81=93:
> > On Wed, 25 Jun 2025 20:19:06 +0930 Qu Wenruo wrote:
> >> =3DE5=3D9C=3DA8 2025/6/25 09:26, Hillf Danton =3DE5=3D86=3D99=3DE9=3D81=
> =3D93:
> >>> On Wed, 25 Jun 2025 06:00:09 +0930 Qu Wenruo wrote:
> >>>> =3D3DE5=3D3D9C=3D3DA8 2025/6/25 00:00, Edward Adam Davis =3D3DE5=3D3D=
> 86=3D3D99=3D3DE9=3D
> >> =3D3D81=3D3D93:
> >>>>> Remove the lock uuid_mutex outside of sget_fc() to avoid the deadloc=
> k
> >>>>> reported by [1].
> >>>>> =3D3D20
> >>>>> [1]
> >>>>> -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
> >>>>>           lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
> >>>>>           down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
> >>>>>           alloc_super+0x204/0x970 fs/super.c:345
> >>> =3D20
> >>> Given kzalloc [3], the syzbot report is false positive (a known lockde=
> p
> >>> issue) as nobody else should acquire s->s_umount lock.
> >>> =3D20
> >>> [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-nex=
> t.=3D
> >> git/tree/fs/super.c?id=3D3D7aacdf6feed1#n319
> >>
> >> Not a false alert either.
> >>
> >> sget_fc() can return an existing super block, we can race between a=3D2=
> 0
> >> mount and an unmount on the same super block.
> >>
> >> In that case it's going to cause problem.
> >>
> >> This is already fixed in the v4 (and later v5) patchset:
> >>
> >> https://lore.kernel.org/linux-btrfs/cover.1750724841.git.wqu@suse.com/
> >>
> > Can v5 survive the syzbot test?
> 
> Yes, I enabled lockdep during v5 tests.
> 
Fine, feel free to show us the Tested-by syzbot gave you.

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

[Qu Wenruo]

#syz test: https://github.com/adam900710/linux.git shutdown

在 2025/6/24 22:41, syzbot 写道:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    5d4809e25903 Add linux-next specific files for 20250620
> git tree:       linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=1421b370580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=58afc4b78b52b7e3
> dashboard link: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
> compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11f1cb0c580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14aff30c580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/16492bf6b788/disk-5d4809e2.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7be284ded1de/vmlinux-5d4809e2.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/467d717f0d9c/bzImage-5d4809e2.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/4a74fbfa0b0f/mount_0.gz
>    fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1030cdd4580000)
> 
> The issue was bisected to:
> 
> commit 7aacdf6feed1ca882339ebd3895a233373b40a1e
> Author: Qu Wenruo <wqu@suse.com>
> Date:   Tue Jun 17 05:19:38 2025 +0000
> 
>      btrfs: delay btrfs_open_devices() until super block is created
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=14d29b0c580000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=16d29b0c580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=12d29b0c580000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
> Fixes: 7aacdf6feed1 ("btrfs: delay btrfs_open_devices() until super block is created")
> 
> BTRFS info (device loop0): using sha256 (sha256-x86_64) checksum algorithm
> BTRFS info (device loop0): disk space caching is enabled
> BTRFS warning (device loop0): space cache v1 is being deprecated and will be removed in a future release, please use -o space_cache=v2
> ======================================================
> WARNING: possible circular locking dependency detected
> 6.16.0-rc2-next-20250620-syzkaller #0 Not tainted
> ------------------------------------------------------
> syz-executor123/5843 is trying to acquire lock:
> ffffffff8e6e9fe8 (uuid_mutex){+.+.}-{4:4}, at: btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
> 
> but task is already holding lock:
> ffff8880328ea0e0 (&type->s_umount_key#41/1){+.+.}-{4:4}, at: alloc_super+0x204/0x970 fs/super.c:345
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
>         lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>         down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
>         alloc_super+0x204/0x970 fs/super.c:345
>         sget_fc+0x329/0xa40 fs/super.c:761
>         btrfs_get_tree_super fs/btrfs/super.c:1867 [inline]
>         btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
>         btrfs_get_tree+0x4c6/0x12d0 fs/btrfs/super.c:2093
>         vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
>         do_new_mount+0x24a/0xa40 fs/namespace.c:3902
>         do_mount fs/namespace.c:4239 [inline]
>         __do_sys_mount fs/namespace.c:4450 [inline]
>         __se_sys_mount+0x317/0x410 fs/namespace.c:4427
>         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
> 
> -> #0 (uuid_mutex){+.+.}-{4:4}:
>         check_prev_add kernel/locking/lockdep.c:3168 [inline]
>         check_prevs_add kernel/locking/lockdep.c:3287 [inline]
>         validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
>         __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
>         lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>         __mutex_lock_common kernel/locking/mutex.c:602 [inline]
>         __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
>         btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
>         open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
>         btrfs_fill_super fs/btrfs/super.c:984 [inline]
>         btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
>         btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
>         btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
>         vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
>         do_new_mount+0x24a/0xa40 fs/namespace.c:3902
>         do_mount fs/namespace.c:4239 [inline]
>         __do_sys_mount fs/namespace.c:4450 [inline]
>         __se_sys_mount+0x317/0x410 fs/namespace.c:4427
>         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
> 
> other info that might help us debug this:
> 
>   Possible unsafe locking scenario:
> 
>         CPU0                    CPU1
>         ----                    ----
>    lock(&type->s_umount_key#41/1);
>                                 lock(uuid_mutex);
>                                 lock(&type->s_umount_key#41/1);
>    lock(uuid_mutex);
> 
>   *** DEADLOCK ***
> 
> 1 lock held by syz-executor123/5843:
>   #0: ffff8880328ea0e0 (&type->s_umount_key#41/1){+.+.}-{4:4}, at: alloc_super+0x204/0x970 fs/super.c:345
> 
> stack backtrace:
> CPU: 1 UID: 0 PID: 5843 Comm: syz-executor123 Not tainted 6.16.0-rc2-next-20250620-syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> Call Trace:
>   <TASK>
>   dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
>   print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2046
>   check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2178
>   check_prev_add kernel/locking/lockdep.c:3168 [inline]
>   check_prevs_add kernel/locking/lockdep.c:3287 [inline]
>   validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3911
>   __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5240
>   lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>   __mutex_lock_common kernel/locking/mutex.c:602 [inline]
>   __mutex_lock+0x182/0xe80 kernel/locking/mutex.c:747
>   btrfs_read_chunk_tree+0xef/0x2170 fs/btrfs/volumes.c:7462
>   open_ctree+0x17f2/0x3a10 fs/btrfs/disk-io.c:3458
>   btrfs_fill_super fs/btrfs/super.c:984 [inline]
>   btrfs_get_tree_super fs/btrfs/super.c:1922 [inline]
>   btrfs_get_tree_subvol fs/btrfs/super.c:2059 [inline]
>   btrfs_get_tree+0xc6f/0x12d0 fs/btrfs/super.c:2093
>   vfs_get_tree+0x8f/0x2b0 fs/super.c:1804
>   do_new_mount+0x24a/0xa40 fs/namespace.c:3902
>   do_mount fs/namespace.c:4239 [inline]
>   __do_sys_mount fs/namespace.c:4450 [inline]
>   __se_sys_mount+0x317/0x410 fs/namespace.c:4427
>   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:0x7fda63124f3a
> 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:00007ffd76f19cb8 EFLAGS: 00000282 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 00007ffd76f19cd0 RCX: 00007fda63124f3a
> RDX: 00002000000004c0 RSI: 00002000000015c0 RDI: 00007ffd76f19cd0
> RBP: 00002000000004c0 R08: 00007ffd76f19d10 R09: 0000000000005598
> R10: 0000000002000000 R11: 0000000000000282 R12: 00002000000015c0
> R13: 00007ffd76f19d10 R14: 0000000000000003 R15: 0000000002000000
>   </TASK>
> BTRFS info (device loop0): rebuilding free space tree
> BTRFS info (device loop0): disabling free space tree
> BTRFS info (device loop0): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)
> BTRFS info (device loop0): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)
> 
> 
> ---
> 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.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> 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
> 

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

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

fs/btrfs/ioctl.c:5417:1: error: function definition is not allowed here
fs/btrfs/ioctl.c:5430:7: error: expected '}'


Tested on:

commit:         86186e83 btrfs: implement remove_bdev super operation ..
git tree:       https://github.com/adam900710/linux.git shutdown
kernel config:  https://syzkaller.appspot.com/x/.config?x=58afc4b78b52b7e3
dashboard link: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6

Note: no patches were applied.

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

[Qu Wenruo]

#syz test: https://github.com/adam900710/linux.git shutdown

在 2025/6/26 16:07, syzbot 写道:
> Hello,
> 
> syzbot tried to test the proposed patch but the build/boot failed:
> 
> fs/btrfs/ioctl.c:5417:1: error: function definition is not allowed here
> fs/btrfs/ioctl.c:5430:7: error: expected '}'
> 
> 
> Tested on:
> 
> commit:         86186e83 btrfs: implement remove_bdev super operation ..
> git tree:       https://github.com/adam900710/linux.git shutdown
> kernel config:  https://syzkaller.appspot.com/x/.config?x=58afc4b78b52b7e3
> dashboard link: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
> compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
> 
> Note: no patches were applied.

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

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com
Tested-by: syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com

Tested on:

commit:         743c198d btrfs: implement remove_bdev super operation ..
git tree:       https://github.com/adam900710/linux.git shutdown
console output: https://syzkaller.appspot.com/x/log.txt?x=13a5b182580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=79da270cec5ffd65
dashboard link: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Qu Wenruo]

在 2025/6/26 09:14, Hillf Danton 写道:
> On Thu, 26 Jun 2025 06:59:14 +0930 Qu Wenruo wrote:
>> =E5=9C=A8 2025/6/25 22:10, Hillf Danton =E5=86=99=E9=81=93:
>>> On Wed, 25 Jun 2025 20:19:06 +0930 Qu Wenruo wrote:
>>>> =3DE5=3D9C=3DA8 2025/6/25 09:26, Hillf Danton =3DE5=3D86=3D99=3DE9=3D81=
>> =3D93:
>>>>> On Wed, 25 Jun 2025 06:00:09 +0930 Qu Wenruo wrote:
>>>>>> =3D3DE5=3D3D9C=3D3DA8 2025/6/25 00:00, Edward Adam Davis =3D3DE5=3D3D=
>> 86=3D3D99=3D3DE9=3D
>>>> =3D3D81=3D3D93:
>>>>>>> Remove the lock uuid_mutex outside of sget_fc() to avoid the deadloc=
>> k
>>>>>>> reported by [1].
>>>>>>> =3D3D20
>>>>>>> [1]
>>>>>>> -> #1 (&type->s_umount_key#41/1){+.+.}-{4:4}:
>>>>>>>            lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5871
>>>>>>>            down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1693
>>>>>>>            alloc_super+0x204/0x970 fs/super.c:345
>>>>> =3D20
>>>>> Given kzalloc [3], the syzbot report is false positive (a known lockde=
>> p
>>>>> issue) as nobody else should acquire s->s_umount lock.
>>>>> =3D20
>>>>> [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-nex=
>> t.=3D
>>>> git/tree/fs/super.c?id=3D3D7aacdf6feed1#n319
>>>>
>>>> Not a false alert either.
>>>>
>>>> sget_fc() can return an existing super block, we can race between a=3D2=
>> 0
>>>> mount and an unmount on the same super block.
>>>>
>>>> In that case it's going to cause problem.
>>>>
>>>> This is already fixed in the v4 (and later v5) patchset:
>>>>
>>>> https://lore.kernel.org/linux-btrfs/cover.1750724841.git.wqu@suse.com/
>>>>
>>> Can v5 survive the syzbot test?
>>
>> Yes, I enabled lockdep during v5 tests.
>>
> Fine, feel free to show us the Tested-by syzbot gave you.
> 

Here you go:

https://lore.kernel.org/linux-btrfs/685d3d4c.050a0220.2303ee.01ca.GAE@google.com/

That's based on a branch with extra patches though.

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Hillf Danton]

On Sun, 29 Jun 2025 13:57:43 +0930 Qu Wenruo wrote:
> 在 2025/6/26 09:14, Hillf Danton 写道:
> > Fine, feel free to show us the Tested-by syzbot gave you.
> > 
> Here you go:
> 
> https://lore.kernel.org/linux-btrfs/685d3d4c.050a0220.2303ee.01ca.GAE@google.com/
> 
> That's based on a branch with extra patches though.
> 
Thanks, feel free to spin with the Tested-by tag added.

Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree

[Qu Wenruo]

在 2025/6/29 14:29, Hillf Danton 写道:
> On Sun, 29 Jun 2025 13:57:43 +0930 Qu Wenruo wrote:
>> 在 2025/6/26 09:14, Hillf Danton 写道:
>>> Fine, feel free to show us the Tested-by syzbot gave you.
>>>
>> Here you go:
>>
>> https://lore.kernel.org/linux-btrfs/685d3d4c.050a0220.2303ee.01ca.GAE@google.com/
>>
>> That's based on a branch with extra patches though.
>>
> Thanks, feel free to spin with the Tested-by tag added.
> 

Normally we only add reported-by/tested-by from syzbot when the 
offending commit is already upstreamed.

Since the series is only in linux-next, not even in btrfs for-next 
branch, I believe no tags will be added in this case.

Thanks,
Qu