commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

commit 108cc873398932af589c295f78c348513b8d70d9 breaks update-grub on btrfs root filesystem

[Alex Romosan]

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.

thank you.

--alex--

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

[Hanabishi]

> Running my own compiled kernel without initramfs

> a git-bisect identified commit
> 108cc873398932af589c295f78c348513b8d70d9 as being the culprit.
Looks like another consequence of the problem described in
https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@gmail.com/

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

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

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.

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

[Hanabishi]

Hello.

May I ask why you guys keep ignoring me completely?
This is clearly a regression for userspace (see my previous reports).
If your answer is "won't fix", state it explicitly please.

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

[Qu Wenruo]

在 2026/9/9 23:48, Hanabishi 写道:
> Hello.
> 
> May I ask why you guys keep ignoring me completely?

If you think we have time to reply every report, then just check how 
many syzbot reports are not addressed.

> This is clearly a regression for userspace (see my previous reports).

Unfortunately it's not.

The problem is there no matter if you have that patch.

There are a lot of ways to make btrfs to report a weird device path even 
before that commit.
> If your answer is "won't fix", state it explicitly please.

Won't fix.

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

[Hanabishi]

I think human reporters deserve more attention than bots. But anyway, thanks for responding.

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

[Qu Wenruo]

在 2026/9/10 09:05, Hanabishi 写道:
> I think human reporters deserve more attention than bots. But anyway, 
> thanks for responding.

BTW, I may consider a different flag/cmd for btrfs device scan ioctl.

So that one can force a device rename, and I can finally put all the 
responsibility to the end user.

But that will not be landed anytime soon.

Meanwhile I would suggest just to use a initramfs to workaround it, so 
that btrfs can be mounted with proper device name (initialized by 
initramfs).

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

[Thorsten Leemhuis]

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/

Exceptions to our #1 rule are rare. They, for example, are made when we
had to fix a vulnerability and tried hard to do so without breaking
something but in the end had to bite the bullet. Is this such a case?

Because if not, it looks more like a situation where Linus would prefer
to live with known problems, as earlier statements from him show:
https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-back-and-forth

But it's easy to misunderstand things from my outside position, which is
why I'm asking.

Ciao, Thorsten

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

[David Sterba]

On Thu, Sep 10, 2026 at 07:28:39AM +0930, Qu Wenruo wrote:
> 在 2026/9/9 23:48, Hanabishi 写道:
> > Hello.
> > 
> > May I ask why you guys keep ignoring me completely?
> 
> If you think we have time to reply every report, then just check how 
> many syzbot reports are not addressed.
> 
> > This is clearly a regression for userspace (see my previous reports).
> 
> Unfortunately it's not.

Are we looking at the same reports??? "My system does not boot after
update" is a regression.

> The problem is there no matter if you have that patch.
> 
> There are a lot of ways to make btrfs to report a weird device path even 
> before that commit.
> > If your answer is "won't fix", state it explicitly please.
> 
> Won't fix.

Can't be, for the same reason the bug 218353 was a regression and had to
be fixed.

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

[David Sterba]

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.

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

[Alex Romosan]

i agree it's a regression. one question (and i am not very familiar
with the underlying principles), how do the other filesystems deal
with this? shouldn't the registering of devices be abstracted out
since i would assume every fs does it or is this something btrfs
specific?

On Fri, Sep 11, 2026 at 8:21 PM David Sterba <dsterba@suse.cz> wrote:
>
> 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.

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

[Qu Wenruo]

在 2026/9/12 04:20, Alex Romosan 写道:
> i agree it's a regression. one question (and i am not very familiar
> with the underlying principles), how do the other filesystems deal
> with this? shouldn't the registering of devices be abstracted out
> since i would assume every fs does it or is this something btrfs
> specific?

Other fses has the same problem on the reported device path.

The difference is other fses saves the device path at mount time and 
doesn't change.

E.g, the same weird device path can be utilized and reported for other 
fses too:

  # cd /dev/
  # mknod weird b 253 2
                  ^^^^^ The same major/minor number for
                        /dev/test/scratch1
  # mkfs.ext4 /dev/weird -F
  # mount /dev/weird /mnt/test
  # mount | tail - n1
  /dev/weird on /mnt/test type ext4 (rw,relatime)

The btrfs specific part is, btrfs can rename the device path on device 
rescan.

That introduced a new problem, should we trust the device path passed in 
for scan?

Normally a device scan is triggered by udev rules, so normally it's sane 
names like "/dev/sda1".
But end users can easily pass random/weird pass in that ioctl to force 
an update on device path, and we're back to the start point.

Furthermore when LVM gets involved, the same dm device can have multiple 
different softlinks.
And a wrong softlink scanned can easily screw a lot of mount detection, 
aka, screw up the most common tool we use, fstests.

Then we can easily have a weird situation where the same device is 
scanned again and again with different names (e.g. "/dev/dm-2" and 
"/dev/test/scratch1"), causing btrfs to report different device name 
depending on the timing.


Another situation is, someone is passing a completely weird name, which 
may not even be accessible by other processes.
The worst situation here is "/proc/self/fd/3", which can be a softlink 
to a block device, but only accessible by that exact process.


One solution to this complex corner case is, to do a proper path 
resolution, and check if the existing recorded path can be accessible, 
if not replace it with the newer one.

However that is not perfect either, firstly related to namespace, the 
device scan can be triggered inside a namespace, and again the path can 
only be accessible inside a certain namespace.

Secondly such path resolution may involve btrfs itself, e.g. the block 
file is not in devfs, but a directory inside btrfs.
Then scan and path resolution may lock the same inode, causing deadlock.

All the history can be found in this patch:

https://lore.kernel.org/linux-btrfs/5e65d9ba5927b4b6985ce819e9e49d082c6e9b45.1789112424.git.wqu@suse.com/T/#u


Now back to the grub problem, firstly it's not causing anyone unable to 
boot, it is only causing the grub2-probe unable to determine where the 
device is.

The reason is for users who are not using initramfs, but direct kernel 
boot. In that case, the rootfs is always using the name "/dev/root".

The lack of initramfs means we do not have proper devfs at boot time, so 
kernel is using that "/dev/root" for rootfs.

But after the system is fully up, a proper devfs is mounted at "/dev/", 
so the older temporary "/dev/root" is no longer accessible.

I can argue that the user space should not really trust the device path 
reported by mount, but utilize the device number reported for the mount 
point. E.g "mountpoint -d", then go through the "/dev/" or libblkid to 
grab the real device.

In fact, even using that weird name, other tools like lsblk can properly 
detect the real device without being confused by the name:

|-test-scratch1 253:2    0   10G  0 lvm  /mnt/test

> 
> On Fri, Sep 11, 2026 at 8:21 PM David Sterba <dsterba@suse.cz> wrote:
>>
>> 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.

It's not not-booting, but just grub2-probe unable to determine which 
device it really has, and so far only affects users without a initramfs.

But if you really want to revert back to fix this particular case, then 
allow the old bad random device rename, back to the starting point of 
the cat-mice game:


diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 4ddabadc9188..f4b36ad1282d 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -749,6 +749,18 @@ const u8 *btrfs_sb_fsid_ptr(const struct 
btrfs_super_block *sb)
         return has_metadata_uuid ? sb->metadata_uuid : sb->fsid;
  }

+static int device_name_cmp(struct btrfs_device *device, const char *path)
+{
+       const char *old_name;
+       int ret;
+
+       rcu_read_lock();
+       old_name = rcu_dereference(device->name);
+       ret = strcmp(old_name, path);
+       rcu_read_unlock();
+       return ret;
+}
+
  /*
   * Add new device to list of registered devices
   *
@@ -869,7 +881,7 @@ static noinline struct btrfs_device 
*device_list_add(const char *path,
                                 MAJOR(path_devt), MINOR(path_devt),
                                 current->comm, task_pid_nr(current));

-       } else if (!device->name || device->devt != path_devt) {
+       } else if (!device->name || device_name_cmp(device, path)) {
                 const char *old_name;

                 /*