Re: btrfs lockdep issue

在 2026/7/14 01:39, Christian Borntraeger 写道:
> Am 13.07.26 um 14:07 schrieb Christian Borntraeger:
> [...]
> 
>>   Possible unsafe locking scenario:
>>         CPU0                    CPU1
>>         ----                    ----
>>    lock(&fs_devs->device_list_mutex);
>>                                 lock(&fs_info->tree_log_mutex);
>>                                 lock(&fs_devs->device_list_mutex);
>>    rlock(&type->i_mutex_dir_key#2);
>>   *** DEADLOCK ***
>> 2 locks held by (udev-worker)/1653:
>>   #0: 0000016c727051c8 (uuid_mutex){+.+.}-{3:3}, at: 
>> btrfs_control_ioctl+0x102/0x1e0
>>   #1: 00000069238564d8 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: 
>> device_list_add.constprop.0+0x148/0xc60 
> 
> So some additional detauls
> -------
> this was a udev-triggered btrfs device scan (BTRFS_IOC_SCAN_DEV) of
> /dev/dm-8. The scanned device belongs to the mounted btrfs root filesystem
> (multipath, the path flapped between /dev/mapper/mpathg2 and /dev/dm-8),
> 
> ---snip---
> BTRFS info: devid 1 device path /dev/mapper/mpathg2 changed to /dev/dm-8 
> scanned by (udev-worker) (1653)
> ---snip---
> Could this be due to  commit 2e8b6bc0ab41ce41e6dfcc204b6cc01d5abbc952
> ("btrfs: avoid unnecessary device path update for the same device")
> ?

I believe you're right.

That commit introduced extra path resolution when we're still holding 
device_list_mutex, meanwhile the path resolution will cause directory 
lookup, thus lead to the above report.

I think I can change the is_same_device() lookup to get rid of the path 
resolution and completely rely on path_devt and device->devt and avoid 
the path resolution completely.

Will send out a patch for you to test soon.

Thanks,
Qu