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

[Qu Wenruo]

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