From: Anand Jain <anand.jain@oracle.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: David Sterba <dsterba@suse.com>,
CHECK_1234543212345@protonmail.com, linux-btrfs@vger.kernel.org,
aromosan@gmail.com
Subject: Re: [PATCH v4 RFC] btrfs: do not skip re-registration for the mounted device
Date: Fri, 8 Mar 2024 19:22:15 +0530 [thread overview]
Message-ID: <03bcd60e-33a7-4bc9-b048-8ae8de6ab9aa@oracle.com> (raw)
In-Reply-To: <CAL3q7H7WpEOBx_66uyzrOH_Lr+Y1j5Gg0gViqGCLQg0vmg9G0A@mail.gmail.com>
On 3/8/24 17:45, Filipe Manana wrote:
> On Fri, Mar 8, 2024 at 2:28 AM Anand Jain <anand.jain@oracle.com> wrote:
>>
>> Filipe,
>>
>> We've received confirmation from the user that the original update-grub
>> issue has been fixed. Additionally, your reported issue using
>> './check btrfs/14[6-9] btrfs/15[8-9]' has been resolved.
>>
>> However, reproducing the bug has been inconsistent on my systems.
>> If you could try checking that as well, it would be appreciated.
>
> Sure, but I'm lost as to what I should test.
> There are several patches, and multiple versions, in the mailing list.
>
> What should be tested on top of the for-next branch?
v4 is the latest version of this patch, which is based on the mainline
master. As you reported that you were able to make btrfs/159 fail with
this patch at v2, v4 of this patch theoretically fixes the bug you
reported. So, I wanted to know if you are still able to reproduce
the bug with v4?
Test case:
./check btrfs/14[6-9] btrfs/15[8-9]
Thanks.
>
> Thanks.
>
>>
>> David,
>>
>> If everything is good with v4, would you like v5 with the RFC
>> removed and "CC: stable@vger.kernel.org # 6.7+" added? Or if
>> it could be done during integration? I'm fine either way.
>>
>> Thanks,
>> Anand
>>
>> On 3/7/24 16:38, Anand Jain wrote:
>>> There are reports that since version 6.7 update-grub fails to find the
>>> device of the root on systems without initrd and on a single device.
>>>
>>> This looks like the device name changed in the output of
>>> /proc/self/mountinfo:
>>>
>>> 6.5-rc5 working
>>>
>>> 18 1 0:16 / / rw,noatime - btrfs /dev/sda8 ...
>>>
>>> 6.7 not working:
>>>
>>> 17 1 0:15 / / rw,noatime - btrfs /dev/root ...
>>>
>>> and "update-grub" shows this error:
>>>
>>> /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?)
>>>
>>> This looks like it's related to the device name, but grub-probe
>>> recognizes the "/dev/root" path and tries to find the underlying device.
>>> However there's a special case for some filesystems, for btrfs in
>>> particular.
>>>
>>> The generic root device detection heuristic is not done and it all
>>> relies on reading the device infos by a btrfs specific ioctl. This ioctl
>>> returns the device name as it was saved at the time of device scan (in
>>> this case it's /dev/root).
>>>
>>> The change in 6.7 for temp_fsid to allow several single device
>>> filesystem to exist with the same fsid (and transparently generate a new
>>> UUID at mount time) was to skip caching/registering such devices.
>>>
>>> This also skipped mounted device. One step of scanning is to check if
>>> the device name hasn't changed, and if yes then update the cached value.
>>>
>>> This broke the grub-probe as it always read the device /dev/root and
>>> couldn't find it in the system. A temporary workaround is to create a
>>> symlink but this does not survive reboot.
>>>
>>> The right fix is to allow updating the device path of a mounted
>>> filesystem even if this is a single device one.
>>>
>>> In the fix, check if the device's major:minor number matches with the
>>> cached device. If they do, then we can allow the scan to happen so that
>>> device_list_add() can take care of updating the device path. The file
>>> descriptor remains unchanged.
>>>
>>> This does not affect the temp_fsid feature, the UUID of the mounted
>>> filesystem remains the same and the matching is based on device major:minor
>>> which is unique per mounted filesystem.
>>>
>>> This covers the path when the device (that exists for all mounted
>>> devices) name changes, updating /dev/root to /dev/sdx. Any other single
>>> device with filesystem and is not mounted is still skipped.
>>>
>>> Note that if a system is booted and initial mount is done on the
>>> /dev/root device, this will be the cached name of the device. Only after
>>> the command "btrfs device scan" it will change as it triggers the
>>> rename.
>>>
>>> The fix was verified by users whose systems were affected.
>>>
>>> Fixes: bc27d6f0aa0e ("btrfs: scan but don't register device on single device filesystem")
>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218353
>>> Link: https://lore.kernel.org/lkml/CAKLYgeJ1tUuqLcsquwuFqjDXPSJpEiokrWK2gisPKDZLs8Y2TQ@mail.gmail.com/
>>> Tested-by: Alex Romosan <aromosan@gmail.com>
>>> Tested-by: CHECK_1234543212345@protonmail.com
>>> Reviewed-by: David Sterba <dsterba@suse.com>
>>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>>> ---
>>> v4:
>>> I removed CC: stable@vger.kernel.org # 6.7+ as this is still in the RFC stage.
>>> I need this patch verified by the bug filer.
>>> Use devt from bdev->bd_dev
>>> Rebased on mainline kernel.org master branch
>>>
>>> v3:
>>> https://lore.kernel.org/linux-btrfs/e2add8d54fbbd813305ba014c11d21d297ad87d0.1709782041.git.anand.jain@oracle.com/T/#u
>>>
>>> fs/btrfs/volumes.c | 57 ++++++++++++++++++++++++++++++++++++++--------
>>> 1 file changed, 47 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>> index d67785be2c77..75bfef1b973b 100644
>>> --- a/fs/btrfs/volumes.c
>>> +++ b/fs/btrfs/volumes.c
>>> @@ -1301,6 +1301,47 @@ int btrfs_forget_devices(dev_t devt)
>>> return ret;
>>> }
>>>
>>> +static bool btrfs_skip_registration(struct btrfs_super_block *disk_super,
>>> + const char *path, dev_t devt,
>>> + bool mount_arg_dev)
>>> +{
>>> + struct btrfs_fs_devices *fs_devices;
>>> +
>>> + /*
>>> + * Do not skip device registration for mounted devices with matching
>>> + * maj:min but different paths. Booting without initrd relies on
>>> + * /dev/root initially, later replaced with the actual root device.
>>> + * A successful scan ensures update-grub selects the correct device.
>>> + */
>>> + list_for_each_entry(fs_devices, &fs_uuids, fs_list) {
>>> + struct btrfs_device *device;
>>> +
>>> + mutex_lock(&fs_devices->device_list_mutex);
>>> +
>>> + if (!fs_devices->opened) {
>>> + mutex_unlock(&fs_devices->device_list_mutex);
>>> + continue;
>>> + }
>>> +
>>> + list_for_each_entry(device, &fs_devices->devices, dev_list) {
>>> + if ((device->devt == devt) &&
>>> + strcmp(device->name->str, path)) {
>>> + mutex_unlock(&fs_devices->device_list_mutex);
>>> +
>>> + /* Do not skip registration */
>>> + return false;
>>> + }
>>> + }
>>> + mutex_unlock(&fs_devices->device_list_mutex);
>>> + }
>>> +
>>> + if (!mount_arg_dev && btrfs_super_num_devices(disk_super) == 1 &&
>>> + !(btrfs_super_flags(disk_super) & BTRFS_SUPER_FLAG_SEEDING))
>>> + return true;
>>> +
>>> + return false;
>>> +}
>>> +
>>> /*
>>> * Look for a btrfs signature on a device. This may be called out of the mount path
>>> * and we are not allowed to call set_blocksize during the scan. The superblock
>>> @@ -1357,18 +1398,14 @@ struct btrfs_device *btrfs_scan_one_device(const char *path, blk_mode_t flags,
>>> goto error_bdev_put;
>>> }
>>>
>>> - if (!mount_arg_dev && btrfs_super_num_devices(disk_super) == 1 &&
>>> - !(btrfs_super_flags(disk_super) & BTRFS_SUPER_FLAG_SEEDING)) {
>>> - dev_t devt;
>>> + if (btrfs_skip_registration(disk_super, path, bdev_handle->bdev->bd_dev,
>>> + mount_arg_dev)) {
>>> + pr_debug("BTRFS: skip registering single non-seed device %s (%d:%d)\n",
>>> + path, MAJOR(bdev_handle->bdev->bd_dev),
>>> + MINOR(bdev_handle->bdev->bd_dev));
>>>
>>> - ret = lookup_bdev(path, &devt);
>>> - if (ret)
>>> - btrfs_warn(NULL, "lookup bdev failed for path %s: %d",
>>> - path, ret);
>>> - else
>>> - btrfs_free_stale_devices(devt, NULL);
>>> + btrfs_free_stale_devices(bdev_handle->bdev->bd_dev, NULL);
>>>
>>> - pr_debug("BTRFS: skip registering single non-seed device %s\n", path);
>>> device = NULL;
>>> goto free_disk_super;
>>> }
>>
next prev parent reply other threads:[~2024-03-08 13:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 11:08 [PATCH v4 RFC] btrfs: do not skip re-registration for the mounted device Anand Jain
2024-03-07 12:12 ` Alex Romosan
2024-03-08 2:28 ` Anand Jain
2024-03-08 12:15 ` Filipe Manana
2024-03-08 13:52 ` Anand Jain [this message]
2024-03-08 14:32 ` Alex Romosan
2024-03-08 14:37 ` Anand Jain
2024-03-08 15:37 ` Alex Romosan
2024-03-08 15:48 ` Anand Jain
2024-03-08 15:54 ` Alex Romosan
2024-03-10 17:11 ` Filipe Manana
2024-03-11 2:00 ` Anand Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03bcd60e-33a7-4bc9-b048-8ae8de6ab9aa@oracle.com \
--to=anand.jain@oracle.com \
--cc=CHECK_1234543212345@protonmail.com \
--cc=aromosan@gmail.com \
--cc=dsterba@suse.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox