All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com>
To: clm@fb.com, dsterba@suse.com, josef@toxicpanda.com,
	 linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	 syzkaller-bugs@googlegroups.com, wqu@suse.com
Subject: [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree
Date: Tue, 24 Jun 2025 06:11:29 -0700	[thread overview]
Message-ID: <685aa401.050a0220.2303ee.0009.GAE@google.com> (raw)

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

             reply	other threads:[~2025-06-24 13:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-24 13:11 syzbot [this message]
2025-06-24 13:56 ` [syzbot] [btrfs?] possible deadlock in btrfs_read_chunk_tree Edward Adam Davis
2025-06-24 14:27   ` 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=685aa401.050a0220.2303ee.0009.GAE@google.com \
    --to=syzbot+fa90fcaa28f5cd4b1fc1@syzkaller.appspotmail.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.