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

[David Sterba <dsterba@suse.cz>]

On Thu, Sep 10, 2026 at 12:39:25PM +0200, Thorsten Leemhuis wrote:
> On 9/9/26 03:13, Qu Wenruo wrote:
> > 在 2026/9/9 09:55, David Sterba 写道:
> >> On Tue, Sep 08, 2026 at 11:59:43PM +0200, Alex Romosan wrote:
> >>>
> >>> [...] 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.
> 
> Well, but our #1 is "no regressions". And the recent change while fixing
> bugs clearly causes one, as Alex's report is afaics at least the third
> about it; the two earlier ones can be found here:
> 
> https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@gmail.com/
> https://lore.kernel.org/linux-btrfs/018a9738-1d4a-43a0-9352-a56d1e541364@gmail.com/
> Plus a repost of the latter here:
> https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@gmail.com/

I'm going to treat this as a regression. And for the record Qu and me
are in disagreement on that. My target is to make the systems boot again
first, the fix may leave some problematic case (like mentioned, devices
in namespaces), but that is probably a lesser problem.