* [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree
@ 2025-06-24 13:11 syzbot
2025-06-24 14:30 ` [PATCH next] btrfs: fix " Edward Adam Davis
2025-06-26 6:05 ` [syzbot] [btrfs?] possible " Qu Wenruo
0 siblings, 2 replies; 15+ messages in thread
From: syzbot @ 2025-06-24 13:11 UTC (permalink / raw)
To: clm, dsterba, josef, linux-btrfs, linux-kernel, syzkaller-bugs,
wqu
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-24 13:11 [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree syzbot
@ 2025-06-24 14:30 ` Edward Adam Davis
2025-06-24 20:30 ` Qu Wenruo
2025-06-26 6:05 ` [syzbot] [btrfs?] possible " Qu Wenruo
1 sibling, 1 reply; 15+ messages in thread
From: Edward Adam Davis @ 2025-06-24 14:30 UTC (permalink / raw)
To: syzbot+fa90fcaa28f5cd4b1fc1
Cc: clm, dsterba, josef, linux-btrfs, linux-kernel, syzkaller-bugs,
wqu
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
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-24 14:30 ` [PATCH next] btrfs: fix " Edward Adam Davis
@ 2025-06-24 20:30 ` Qu Wenruo
2025-06-24 23:56 ` Hillf Danton
0 siblings, 1 reply; 15+ messages in thread
From: Qu Wenruo @ 2025-06-24 20:30 UTC (permalink / raw)
To: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1
Cc: clm, dsterba, josef, linux-btrfs, linux-kernel, syzkaller-bugs,
wqu
在 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) {
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-24 20:30 ` Qu Wenruo
@ 2025-06-24 23:56 ` Hillf Danton
2025-06-25 10:49 ` Qu Wenruo
0 siblings, 1 reply; 15+ messages in thread
From: Hillf Danton @ 2025-06-24 23:56 UTC (permalink / raw)
To: Qu Wenruo
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
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) {
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-24 23:56 ` Hillf Danton
@ 2025-06-25 10:49 ` Qu Wenruo
2025-06-25 12:40 ` Hillf Danton
0 siblings, 1 reply; 15+ messages in thread
From: Qu Wenruo @ 2025-06-25 10:49 UTC (permalink / raw)
To: Hillf Danton
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
在 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) {
>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-25 10:49 ` Qu Wenruo
@ 2025-06-25 12:40 ` Hillf Danton
2025-06-25 21:29 ` Qu Wenruo
0 siblings, 1 reply; 15+ messages in thread
From: Hillf Danton @ 2025-06-25 12:40 UTC (permalink / raw)
To: Qu Wenruo
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
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?
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-25 12:40 ` Hillf Danton
@ 2025-06-25 21:29 ` Qu Wenruo
2025-06-25 23:44 ` Hillf Danton
0 siblings, 1 reply; 15+ messages in thread
From: Qu Wenruo @ 2025-06-25 21:29 UTC (permalink / raw)
To: Hillf Danton
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
在 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.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-25 21:29 ` Qu Wenruo
@ 2025-06-25 23:44 ` Hillf Danton
2025-06-29 4:27 ` Qu Wenruo
0 siblings, 1 reply; 15+ messages in thread
From: Hillf Danton @ 2025-06-25 23:44 UTC (permalink / raw)
To: Qu Wenruo
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-25 23:44 ` Hillf Danton
@ 2025-06-29 4:27 ` Qu Wenruo
2025-06-29 4:59 ` Hillf Danton
0 siblings, 1 reply; 15+ messages in thread
From: Qu Wenruo @ 2025-06-29 4:27 UTC (permalink / raw)
To: Hillf Danton
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
在 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.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-29 4:27 ` Qu Wenruo
@ 2025-06-29 4:59 ` Hillf Danton
2025-06-29 5:05 ` Qu Wenruo
0 siblings, 1 reply; 15+ messages in thread
From: Hillf Danton @ 2025-06-29 4:59 UTC (permalink / raw)
To: Qu Wenruo
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH next] btrfs: fix deadlock in btrfs_read_chunk_tree
2025-06-29 4:59 ` Hillf Danton
@ 2025-06-29 5:05 ` Qu Wenruo
0 siblings, 0 replies; 15+ messages in thread
From: Qu Wenruo @ 2025-06-29 5:05 UTC (permalink / raw)
To: Hillf Danton, Qu Wenruo
Cc: Edward Adam Davis, syzbot+fa90fcaa28f5cd4b1fc1, clm, josef,
linux-btrfs, linux-kernel, syzkaller-bugs
在 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree
2025-06-24 13:11 [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree syzbot
2025-06-24 14:30 ` [PATCH next] btrfs: fix " Edward Adam Davis
@ 2025-06-26 6:05 ` Qu Wenruo
2025-06-26 6:37 ` syzbot
1 sibling, 1 reply; 15+ messages in thread
From: Qu Wenruo @ 2025-06-26 6:05 UTC (permalink / raw)
To: syzbot, clm, dsterba, josef, linux-btrfs, linux-kernel,
syzkaller-bugs, wqu
#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
>
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree
2025-06-26 6:05 ` [syzbot] [btrfs?] possible " Qu Wenruo
@ 2025-06-26 6:37 ` syzbot
2025-06-26 8:40 ` Qu Wenruo
0 siblings, 1 reply; 15+ messages in thread
From: syzbot @ 2025-06-26 6:37 UTC (permalink / raw)
To: clm, dsterba, josef, linux-btrfs, linux-kernel, quwenruo.btrfs,
syzkaller-bugs, wqu
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree
2025-06-26 6:37 ` syzbot
@ 2025-06-26 8:40 ` Qu Wenruo
2025-06-26 12:30 ` syzbot
0 siblings, 1 reply; 15+ messages in thread
From: Qu Wenruo @ 2025-06-26 8:40 UTC (permalink / raw)
To: syzbot, clm, dsterba, josef, linux-btrfs, linux-kernel,
quwenruo.btrfs, syzkaller-bugs
#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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree
2025-06-26 8:40 ` Qu Wenruo
@ 2025-06-26 12:30 ` syzbot
0 siblings, 0 replies; 15+ messages in thread
From: syzbot @ 2025-06-26 12:30 UTC (permalink / raw)
To: clm, dsterba, josef, linux-btrfs, linux-kernel, quwenruo.btrfs,
syzkaller-bugs, wqu
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2025-06-29 5:05 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-24 13:11 [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree syzbot
2025-06-24 14:30 ` [PATCH next] btrfs: fix " Edward Adam Davis
2025-06-24 20:30 ` Qu Wenruo
2025-06-24 23:56 ` Hillf Danton
2025-06-25 10:49 ` Qu Wenruo
2025-06-25 12:40 ` Hillf Danton
2025-06-25 21:29 ` Qu Wenruo
2025-06-25 23:44 ` Hillf Danton
2025-06-29 4:27 ` Qu Wenruo
2025-06-29 4:59 ` Hillf Danton
2025-06-29 5:05 ` Qu Wenruo
2025-06-26 6:05 ` [syzbot] [btrfs?] possible " Qu Wenruo
2025-06-26 6:37 ` syzbot
2025-06-26 8:40 ` Qu Wenruo
2025-06-26 12:30 ` syzbot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).