lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d28b18c-3477-83ec-ef89-cdaf6ca7ebee@oracle.com>
Date: Mon, 22 Jan 2024 09:35:22 +0800
From: Anand Jain <anand.jain@...cle.com>
To: Alex Romosan <aromosan@...il.com>
Cc: CHECK_1234543212345@...tonmail.com, brauner@...nel.org,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        Linux kernel regressions list <regressions@...ts.linux.dev>,
        linux-kernel@...r.kernel.org, Chris Mason <clm@...com>,
        Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>,
        dsterba@...e.cz
Subject: Re: [btrfs] commit bc27d6f0aa0e4de184b617aceeaf25818cc646de breaks
 update-grub



On 22/01/2024 08:07, Alex Romosan wrote:
> update-grub still doesn't work 6.8-rc1
> 
> so i did:
> 
> # cat /proc/self/mountinfo | grep btrfs
> 21 1 0:19 / / rw,relatime shared:1 - btrfs /dev/root
> rw,ssd,discard=async,space_cache,subvolid=5,subvol=/
> 

The latest Btrfs kernel expect one MAJ:MIN for a block device,
but multiple nodes here point to the same root device:

   /dev/root MAJ1:MIN1 \___ root-device
   /dev/sda1 MAJ2:MIN2 /

To fix, I'm exploring communication through block-device nodes
with a temporary signature tag on the superblock for identification.
Community feedback is pending, and potentially synchronization issues
maybe a concer.

> the difference from your test case is that it doesn't reference
> the disk device but /dev/root which on my system doesn't exist. could this
> be the problem?
> 

How are you reproducing this? I tried with Oracle Linux (OL), Fedora,
and Arch Linux, but they didn't show /dev/root as the root device.

Thanks, Anand

> --alex--
> 
> 
> On Fri, Jan 12, 2024 at 12:24 AM Anand Jain <anand.jain@...cle.com> wrote:
>>
>>
>>
>> On 11/01/2024 22:36, David Sterba wrote:
>>> On Thu, Jan 11, 2024 at 04:50:56PM +0100, David Sterba wrote:
>>>> On Thu, Jan 11, 2024 at 12:45:50PM +0100, Thorsten Leemhuis wrote:
>>>>> [Adding Anand Jain, the author of the culprit to the list of recipients;
>>>>> furthermore CCing the the Btrfs maintainers and the btrfs list; also
>>>>> CCing regression list, as it should be in the loop for regressions:
>>>>> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>>>>>
>>>>> On 08.01.24 15:11, 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.
>>>>>>
>>>>>> Since version 6.7-rc1 i haven't been able to to a grub-update,
>>>>>>
>>>>>> instead i get this error:
>>>>>>
>>>>>> grub-probe: error: cannot find a device for / (is /dev mounted?) solid
>>>>>> state drive
>>>>>>
>>>>>> 6.6 was the last version that worked.
>>>>>>
>>>>>> Today I did a git-bisect between these two versions which identified
>>>>>> commit bc27d6f0aa0e4de184b617aceeaf25818cc646de btrfs: scan but don't
>>>>>> register device on single device filesystem as the culprit. reverting
>>>>>> this commit from 6.7 final allowed me to run update-grub again.
>>>>>>
>>>>>> not sure if this is the intended behavior or if i'm missing some other
>>>>>> kernel options. any help/fixes would be appreciated.
>>>>>>
>>>>>> thank you.
>>>>>
>>>>> Thanks for the report. To be sure the issue doesn't fall through the
>>>>> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
>>>>> tracking bot:
>>>>>
>>>>> #regzbot ^introduced bc27d6f0aa0e4de184b617aceeaf25818cc646de
>>>>> #regzbot title btrfs: update-grub broken (cannot find a device for / (is
>>>>> /dev mounted?))
>>>>> #regzbot ignore-activity
>>>>
>>>> The bug is also tracked at https://bugzilla.kernel.org/show_bug.cgi?id=218353 .
>>>
>>> About the fix: we can't simply revert the patch because the temp_fsid
>>> depends on that. A workaround could be to check if the device path is
>>> "/dev/root" and still register the device. But I'm not sure if this does
>>> not break the use case that Steamdeck needs, as it's for the root
>>> partition.
>>
>>
>> Thank you for the report.
>>
>> The issue seems more complex than a simple scenario, as the following
>> test-case works well:
>>
>>     $ mount /dev/sdb1 /btrfs
>>     $ cat /proc/self/mountinfo | grep btrfs
>> 345 63 0:34 / /btrfs rw,relatime shared:179 - btrfs /dev/sdb1
>> rw,space_cache=v2,subvolid=5,subvol=/
>>
>> However, the relevant part of the commit
>> bc27d6f0aa0e4de184b617aceeaf25818cc646de that may be failing could
>> be in identifying a device, whether it is the same or different
>> For this, we use:
>>
>>        lookup_bdev(path, &path_devt);
>>
>> and match with the devt(MAJ:MIN) saved in the btrfs_device;
>> would this work during initrd? I need to dig more. Trying
>> to figure out how can I reproduce this.
>>
>> Thanks, Anand

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ