[PATCH v2] s390/iomem: register initrd as an iomem resource when retain_initrd is set

[PATCH v2] s390/iomem: register initrd as an iomem resource when retain_initrd is set

[Joseph Cathcart]

Currently, /proc/iomem contains no reference to initrd memory, even
when initrd is retained and still held in RAM. This makes the memory
ranges invisible from userspace, and unusable to programs such as
kexec. (A sysfs bin file is created for initrd, but this doesn't
help programs which need the explicit memory ranges)

Add initrd to standard_resources[] unconditionally. Add initrd as a
child of iomem_resources only if retain_initrd is specified.

strstr() could match substrings like "retain_initrd=0" or
"no_retain_initrd", but this is how PPC chose to check for
"retain_initrd" param too. (arch/powerpc/kexec/ranges.c)

Signed-off-by: Joseph Cathcart <josephc@linux.ibm.com>
---
 arch/s390/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index b60284328fe3..cd61e286628a 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -481,15 +481,22 @@ static struct resource bss_resource = {
 	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
+static struct resource initrd_resource = {
+	.name = "initrd",
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+};
+
 static struct resource __initdata *standard_resources[] = {
 	&code_resource,
 	&data_resource,
 	&bss_resource,
+	&initrd_resource,
 };
 
 static void __init setup_resources(void)
 {
 	struct resource *res, *std_res, *sub_res;
+	bool retain_initrd = false;
 	phys_addr_t start, end;
 	int j;
 	u64 i;
@@ -501,6 +508,19 @@ static void __init setup_resources(void)
 	bss_resource.start = __pa_symbol(__bss_start);
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
+	if (strstr(boot_command_line, "retain_initrd"))
+		retain_initrd = true;
+	if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && retain_initrd) {
+		unsigned long initrd_addr, initrd_size;
+	
+		if (get_physmem_reserved(RR_INITRD, &initrd_addr, &initrd_size)) {
+			initrd_resource.start = initrd_addr;
+			initrd_resource.end = initrd_resource.start + initrd_size - 1;
+		} else {
+			retain_initrd = false;
+		}
+	}
+
 	for_each_mem_range(i, &start, &end) {
 		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
@@ -517,6 +537,8 @@ static void __init setup_resources(void)
 
 		for (j = 0; j < ARRAY_SIZE(standard_resources); j++) {
 			std_res = standard_resources[j];
+			if (std_res == &initrd_resource && !retain_initrd)
+				continue;
 			if (std_res->start < res->start ||
 			    std_res->start > res->end)
 				continue;
-- 
2.55.0

base commit: 0f23d56f17fdfc7db69d51f64c8b91bbab947aa9

Re: [PATCH v2] s390/iomem: register initrd as an iomem resource when retain_initrd is set

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Imprecise substring matching for 'retain_initrd' creates a split-brain state with the core kernel, causing freed initrd memory to remain falsely marked as BUSY in the iomem resource map.
- [Medium] When CONFIG_BLK_DEV_INITRD is disabled, a bogus 1-byte initrd resource at address 0x0 is incorrectly registered if 'retain_initrd' matches in the boot command line.
--

--- Patch [1]: [PATCH v2] s390/iomem: register initrd as an iomem resource when retain_initrd is set ---
commit 0f4223b27c45aff988c662d5fb36a4161cc6901c
Author: Joseph Cathcart <josephc@linux.ibm.com>

s390/iomem: register initrd as an iomem resource when retain_initrd is set

This patch unconditionally adds initrd to the standard_resources array and
conditionally registers it as an iomem resource if the retain_initrd boot
parameter is present.

> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index b60284328fe3d..cd61e286628a0 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
[ ... ]
> @@ -501,6 +508,19 @@ static void __init setup_resources(void)
>  	bss_resource.start = __pa_symbol(__bss_start);
>  	bss_resource.end = __pa_symbol(__bss_stop) - 1;
>  
> +	if (strstr(boot_command_line, "retain_initrd"))
> +		retain_initrd = true;

[Severity: Medium]
Is this substring match too broad? If a user passes "retain_initrd=0" or
"no_retain_initrd" on the command line, this will still evaluate to true.

The core kernel will correctly evaluate the exact parameter and free the
initrd memory, but s390 setup might then register the freed memory as an
IORESOURCE_BUSY initrd resource in /proc/iomem. 

Will this leave a dangling resource entry covering memory that is actively
reused by the buddy allocator?

> +	if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && retain_initrd) {
> +		unsigned long initrd_addr, initrd_size;
> +	
> +		if (get_physmem_reserved(RR_INITRD, &initrd_addr, &initrd_size)) {
> +			initrd_resource.start = initrd_addr;
> +			initrd_resource.end = initrd_resource.start + initrd_size - 1;
> +		} else {
> +			retain_initrd = false;
> +		}
> +	}

[Severity: Medium]
What happens here if CONFIG_BLK_DEV_INITRD is disabled and retain_initrd
matched in the boot command line?

Since this block is skipped entirely, retain_initrd is never reset to
false. Won't the subsequent standard resources loop then process an
uninitialized initrd_resource (which defaults to 0-bounds), resulting in
a bogus 1-byte initrd resource registered at physical address 0x0?

> +
>  	for_each_mem_range(i, &start, &end) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818162436.12383-1-josephc@linux.ibm.com?part=1