[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 <w...@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+fa90fc...@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 syzk...@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

[Edward Adam Davis]

#syz test

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) {

[syzbot]

Hello,

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

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

Tested on:

commit: 2ae2aaaf Add linux-next specific files for 20250624
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11b96b70580000
kernel config: https://syzkaller.appspot.com/x/.config?x=16ab4ce1313fe0b0

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

patch: https://syzkaller.appspot.com/x/patch.diff?x=1198370c580000

Note: testing is done by a robot and is best-effort only.

[Edward Adam Davis]

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

[1]

Fixes: 7aacdf6feed1 ("btrfs: delay btrfs_open_devices() until super block is created")

Reported-by: syzbot+fa90fc...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fa90fcaa28f5cd4b1fc1
Tested-by: syzbot+fa90fc...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
fs/btrfs/super.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

--
2.43.0

[Qu Wenruo]

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

Just run the test case generic/604.

[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+fa90fc...@syzkaller.appspotmail.com

> > Closes: https://syzkaller.appspot.com/bug?extid=3Dfa90fcaa28f5cd4b1fc1

> > Tested-by: syzbot+fa90fc...@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <ead...@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) {

[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.175072...@suse.com/

Thanks,
Qu

[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.175072...@suse.com/
>

Can v5 survive the syzbot test?

[Qu Wenruo]

Yes, I enabled lockdep during v5 tests.

[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.175072...@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.

[Qu Wenruo]

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

[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.

[Qu Wenruo]

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

[syzbot]

Hello,

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

Reported-by: syzbot+fa90fc...@syzkaller.appspotmail.com
Tested-by: syzbot+fa90fc...@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.

[Qu Wenruo]

Here you go:

https://lore.kernel.org/linux-btrfs/685d3d4c.050a022...@google.com/

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

[Hillf Danton]

Thanks, feel free to spin with the Tested-by tag added.

[Qu Wenruo]

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

[syzbot]

Auto-closing this bug as obsolete.
No recent activity, existing reproducers are no longer triggering the issue.