Re: [PATCH v3 4/7] block: discover root by DPS partition type UUID

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] init: unconditional DPS discovery in prepare_namespace() breaks nodev root
- [High] init: DPS root auto-discovery in lookup_root_device() rejected by maintainer
--

commit 810f32136ad63589849b2f0f1f1255fa412bff0c
Author: Vincent Mailhol <mailhol@kernel.org>

block: discover root by DPS partition type UUID

This commit adds root block device discovery using the architecture's
Discoverable Partitions Specification (DPS) root partition type UUID when
root= and ROOT_DEV are not set. It reads LoaderDevicePartUUID from EFI to
locate the disk containing the active EFI System Partition and searches that
disk for a matching root partition.

Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/

> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index b0dccad209710..c1106e3cab3dc 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -406,10 +406,24 @@ static int __init lookup_root_device(const char *root_device_name, dev_t *dev)
>  {
>  	int err;
>  
> -	err = early_lookup_bdev(root_device_name, dev);
> +	if (root_device_name[0]) {
> +		err = early_lookup_bdev(root_device_name, dev);
> +		if (err == -EINVAL && root_wait) {
> +			pr_err("VFS: root= is invalid; disabling rootwait.\n");
> +			root_wait = 0;
> +		}
> +		return err;
> +	}
> +
> +	err = early_lookup_dps_root(dev);

[Severity: High]
As reported by Christian Brauner on v1 [1], does in-kernel DPS root
auto-discovery belong in the kernel?

On v1 of this series, the VFS subsystem maintainer objected to adding DPS
auto-discovery to the kernel, noting that DPS is complex userspace policy and
should not be implemented in the kernel for root auto-discovery.

This patch still adds early_lookup_dps_root() in block/early-lookup.c and
wires it into prepare_namespace() -> parse_root_device() ->
lookup_root_device() in init/do_mounts.c when root= and ROOT_DEV are unset.

>  	if (err == -EINVAL && root_wait) {
> -		pr_err("VFS: root= is invalid; disabling rootwait.\n");
> +		pr_err("VFS: Root discovery is unavailable; disabling rootwait.\n");
>  		root_wait = 0;
> +	} else if (err == -ENODEV) {
> +		pr_err("VFS: No discoverable root partition found; aborting.\n");
> +		root_wait = 0;
> +		*dev = 0;
> +		return 0;
>  	}
>  	return err;
>  }

[ ... ]

> @@ -480,7 +497,7 @@ void __init prepare_namespace(void)
>  
>  	md_run_setup();
>  
> -	if (saved_root_name[0])
> +	if (saved_root_name[0] || !ROOT_DEV)
>  		ROOT_DEV = parse_root_device(saved_root_name);

[Severity: High]
Does calling parse_root_device() unconditionally when saved_root_name is
empty and ROOT_DEV is 0 cause a regression for nodev root filesystems
(such as tmpfs, ramfs, virtiofs, or 9p) configured via rootfstype= without
root=?

Previously, when booting without root= and with rootfstype= specifying a
nodev filesystem, prepare_namespace() skipped parse_root_device() and left
ROOT_DEV as 0, allowing mount_root() to reach case 0 and call
mount_nodev_root():

init/do_mounts.c:mount_root() {
	switch (ROOT_DEV) {
	...
	case 0:
		if (root_device_name && root_fs_names &&
		    mount_nodev_root(root_device_name) == 0)
			break;
		fallthrough;
	default:
		mount_block_root(root_device_name);
		break;
	}
}

With this change, prepare_namespace() invokes parse_root_device() ->
lookup_root_device() -> early_lookup_dps_root() before mount_root() checks
for a nodev rootfstype=.

If the system boots via EFI from a disk that happens to contain a partition
matching the architecture DPS root type UUID (for example, a VM or host disk
with an installed OS image booting a kernel with rootfstype=tmpfs or
rootfstype=virtiofs and no root=), early_lookup_dps_root() sets ROOT_DEV to
that block partition. mount_root() then skips case 0 and enters
mount_block_root() instead of mount_nodev_root(), either hijacking the root
mount or panicking when the nodev filesystem rejects /dev/root.

Even when no matching DPS partition exists on the ESP disk (or when
LoaderDevicePartUUID is absent), early_lookup_dps_root() and
lookup_root_device() unconditionally log KERN_ERR messages such as:

	pr_err("VFS: No discoverable root partition found; aborting.\n");

or:

	pr_err("VFS: Unable to get EFI partition UUID: %pe, skipping root partition discovery\n",
		ERR_PTR(err));

right before mount_nodev_root() proceeds to mount the nodev root filesystem.

[1] https://lore.kernel.org/r/20260617-irritation-rollen-wirst-7d636cbfec92@brauner

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261102-discoverable-root_partitions-v3-0-27f04b69b7ab@kernel.org?part=4