Re: commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

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

在 2026/9/9 09:55, David Sterba 写道:
> On Tue, Sep 08, 2026 at 11:59:43PM +0200, Alex Romosan wrote:
>> Please Cc me as I am not subscribed to the list.
>>
>> Running my own compiled kernel without initramfs on a lenovo thinkpad
>> x1 carbon gen 7.  The linux disk is the only disk on the system. Since
>> version 7.3-rc1 i haven't been able to to a grub-update, instead i get
>> this error:
>>
>> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
>>
>> 7.2 is fine. a git-bisect identified commit
>> 108cc873398932af589c295f78c348513b8d70d9 as being the culprit.
>> reverting this commit from 7.3-rc2 allowed me to run grub-update
>> again.
>>
>> this is not the first time i reported grub-update being broken on
>> btrfs. i reported exactly the same problem on jan 8, 2024
>> (https://lkml.iu.edu/hypermail/linux/kernel/2401.1/00596.html). maybe
>> the discussion that followed would help come up with a fix that will
>> make everybody happy.
> 
> I remember debugging that one, https://bugzilla.kernel.org/show_bug.cgi?id=218353
> Reverting 108cc8733989 ("btrfs: fix a lockdep caused by path resolution
> during device scan") would bring back the lockdep warning and there is a
> locking problem.
> 
> The commit says it's fixing 2e8b6bc0ab41 ("btrfs: avoid unnecessary
> device path update for the same device"), the difference is in lines
> 
> (https://bugzilla.suse.com/show_bug.cgi?id=1230641)
> 
> -       } else if (!device->name || strcmp(device->name->str, path)) {
> +	} else if (!device->name || !is_same_device(device, path)) {
> 
> Which gets changed to (by 108cc8733989):
> 
> -       } else if (!device->name || !is_same_device(device, path)) {
> +       } else if (!device->name || device->devt != path_devt) {
> 
> Each change is reaction to a bug, I don't see a clear fix which will
> make it work in all cases.

And I want to add that, the previous path based comparison is also 
problematic for namespaces/weird block device names.

Although not common, it's definitely possible to map weird block file 
name into a namespace.

Thus the path based comparison is not reliable in the first place, no to 
mention the later lockdep problems.