Re: [PATCH v3 0/6] btrfs: use the super_block as bdev holder

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2025/6/19 22:59, David Sterba 写道:
> On Tue, Jun 17, 2025 at 02:49:33PM +0930, Qu Wenruo wrote:
>> [CHANGELOG]
>> v3:
>> - Drop the btrfs_fs_devices::opened split
>>    It turns out to cause problems during tests.
>>
>> - Extra cleanup related to the btrfs_get_tree_*()
>>    Now the re-entry through vfs_get_tree() is completely dropped.
>>
>> - Extra comments explaining the sget_fc() behavior
>>
>> - Call bdev_fput() instead of fput()
>>    This alignes us to all the other fses.
>>
>> - Updated patch to delay btrfs_open_devices() until sget_fc()
>>    Instead of relying on the previous solution (split
>>    btrfs_open_devices::opened), just expand the uuid_mutex critical
>>    section.
> 
> I've added the patches to linux-next for testing.
> 

Please drop the series.

The problem is exactly in the btrfs_open_devices() handling.

The new delayed behavior is causing lockdep warning, as now sget_fc() is 
called with uuid_mutex hold, this can cause a ABBA deadlock:

[   50.807904] ======================================================
[   50.809738] WARNING: possible circular locking dependency detected
[   50.811563] 6.16.0-rc1-custom+ #258 Not tainted
[   50.813040] ------------------------------------------------------
[   50.814761] mount/798 is trying to acquire lock:
[   50.816114] ffffffffa070b068 (uuid_mutex){+.+.}-{4:4}, at: 
btrfs_read_chunk_tree+0x7d/0x870 [btrfs]
[   50.818690]
[   50.818690] but task is already holding lock:
[   50.820964] ffff8881055d50e0 (&type->s_umount_key#46/1){+.+.}-{4:4}, 
at: alloc_super+0xe0/0x3c0
[   50.823553]
[   50.823553] which lock already depends on the new lock.
[   50.823553]
[   50.825852]
[   50.825852] the existing dependency chain (in reverse order) is:
[   50.827858]
[   50.827858] -> #1 (&type->s_umount_key#46/1){+.+.}-{4:4}:
[   50.829749]        down_write_nested+0x38/0xc0
[   50.831063]        alloc_super+0xe0/0x3c0
[   50.832175]        sget_fc+0x66/0x400
[   50.833203]        btrfs_get_tree+0x195/0x620 [btrfs]
[   50.834653]        vfs_get_tree+0x2c/0xe0
[   50.835767]        vfs_cmd_create+0x57/0xd0
[   50.836979]        __do_sys_fsconfig+0x4c0/0x660
[   50.838244]        do_syscall_64+0x6c/0x2c0
[   50.839397]        entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   50.840968]
[   50.840968] -> #0 (uuid_mutex){+.+.}-{4:4}:
[   50.842767]        __lock_acquire+0x14b7/0x22a0
[   50.844138]        lock_acquire+0xc9/0x300
[   50.845427]        __mutex_lock+0xb9/0xe00
[   50.846625]        btrfs_read_chunk_tree+0x7d/0x870 [btrfs]
[   50.848272]        open_ctree+0x9aa/0x1483 [btrfs]
[   50.849654]        btrfs_get_tree.cold+0xf3/0x19d [btrfs]
[   50.851173]        vfs_get_tree+0x2c/0xe0
[   50.852443]        vfs_cmd_create+0x57/0xd0
[   50.853768]        __do_sys_fsconfig+0x4c0/0x660
[   50.855094]        do_syscall_64+0x6c/0x2c0
[   50.856260]        entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   50.857773]
[   50.857773] other info that might help us debug this:
[   50.857773]
[   50.859955]  Possible unsafe locking scenario:
[   50.859955]
[   50.861558]        CPU0                    CPU1
[   50.862816]        ----                    ----
[   50.864067]   lock(&type->s_umount_key#46/1);
[   50.865367]                                lock(uuid_mutex);
[   50.866962] 
lock(&type->s_umount_key#46/1);
[   50.868821]   lock(uuid_mutex);
[   50.869716]
[   50.869716]  *** DEADLOCK ***
[   50.869716]
[   50.871325] 2 locks held by mount/798:
[   50.872370]  #0: ffff888102ea2c70 (&fc->uapi_mutex){+.+.}-{4:4}, at: 
__do_sys_fsconfig+0x48f/0x660
[   50.874799]  #1: ffff8881055d50e0 
(&type->s_umount_key#46/1){+.+.}-{4:4}, at: alloc_super+0xe0/0x3c0
[   50.877270]
[   50.877270] stack backtrace:
[   50.878480] CPU: 3 UID: 0 PID: 798 Comm: mount Not tainted 
6.16.0-rc1-custom+ #258 PREEMPT(full)
[   50.878486] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
unknown 02/02/2022
[   50.878488] Call Trace:
[   50.878493]  <TASK>
[   50.878498]  dump_stack_lvl+0x76/0xa0
[   50.878505]  print_circular_bug.cold+0x185/0x1d0
[   50.878512]  check_noncircular+0x169/0x190
[   50.878518]  __lock_acquire+0x14b7/0x22a0
[   50.878526]  lock_acquire+0xc9/0x300
[   50.878529]  ? btrfs_read_chunk_tree+0x7d/0x870 [btrfs]
[   50.878626]  ? lock_acquire+0xc9/0x300
[   50.878628]  ? fs_reclaim_acquire+0x4f/0xe0
[   50.878634]  __mutex_lock+0xb9/0xe00
[   50.878640]  ? btrfs_read_chunk_tree+0x7d/0x870 [btrfs]
[   50.878685]  ? fs_reclaim_acquire+0x4f/0xe0
[   50.878687]  ? lock_release+0xdd/0x2e0
[   50.878690]  ? btrfs_read_chunk_tree+0x7d/0x870 [btrfs]
[   50.878726]  ? btrfs_read_chunk_tree+0x7d/0x870 [btrfs]
[   50.878759]  btrfs_read_chunk_tree+0x7d/0x870 [btrfs]
[   50.878793]  ? btrfs_root_node+0x22/0x220 [btrfs]
[   50.878844]  ? find_held_lock+0x2b/0x80
[   50.878849]  ? btrfs_root_node+0x9c/0x220 [btrfs]
[   50.878912]  ? load_super_root+0x95/0xc3 [btrfs]
[   50.878976]  open_ctree+0x9aa/0x1483 [btrfs]
[   50.879015]  btrfs_get_tree.cold+0xf3/0x19d [btrfs]
[   50.879053]  ? fscontext_read+0x11d/0x130
[   50.879056]  ? __do_sys_fsconfig+0x48f/0x660
[   50.879058]  vfs_get_tree+0x2c/0xe0
[   50.879062]  ? capable+0x3a/0x60
[   50.879066]  vfs_cmd_create+0x57/0xd0
[   50.879069]  __do_sys_fsconfig+0x4c0/0x660
[   50.879071]  do_syscall_64+0x6c/0x2c0
[   50.879077]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   50.879080] RIP: 0033:0x7f3442f9eefe
[   50.879086] Code: 73 01 c3 48 8b 0d 12 be 0c 00 f7 d8 64 89 01 48 83 
c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e2 bd 0c 00 f7 d8 64 89 01 48
[   50.879088] RSP: 002b:00007ffe661382a8 EFLAGS: 00000246 ORIG_RAX: 
00000000000001af
[   50.879092] RAX: ffffffffffffffda RBX: 0000558220e95430 RCX: 
00007f3442f9eefe
[   50.879094] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 
0000000000000003
[   50.879094] RBP: 00007ffe661382e0 R08: 0000000000000000 R09: 
0000000000000000
[   50.879095] R10: 0000000000000000 R11: 0000000000000246 R12: 
00007f34430c8980
[   50.879096] R13: 0000000000000000 R14: 0000558220e96720 R15: 
00007f34430bd8e0
[   50.879099]  </TASK>

I'll need to find out a way to make sget_fc() call without holding 
uuid_mutex instead.

Thanks,
Qu