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@xxxxxxxxx/
https://lore.kernel.org/linux-btrfs/018a9738-1d4a-43a0-9352-a56d1e541364@xxxxxxxxx/
Plus a repost of the latter here:
https://lore.kernel.org/linux-btrfs/dfbe1e27-dab8-4d55-8cf3-0b28eeac5df4@xxxxxxxxx/

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