All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Joseph Cathcart" <josephc@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH v3] s390/iomem: register initrd as an iomem resource when retain_initrd is set
Date: Tue, 18 Aug 2026 16:48:06 +0000	[thread overview]
Message-ID: <20260818164807.34E201F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260818163902.14422-1-josephc@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The logic to conditionally register the initrd resource is entirely dead code because it is gated by a condition that unconditionally evaluates to false.
- [Medium] Using `strstr()` to parse `retain_initrd` from the command line incorrectly matches substrings like `retain_initrd=0`, creating a state mismatch with generic kernel memory management.
--

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

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

This commit adds the initrd memory range to the standard resources in
/proc/iomem on s390. It conditionally registers it as a child of
iomem_resources if retain_initrd is specified on the boot command line.

> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index b60284328fe3d..45b0e19bdab2c 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
[ ... ]
>  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 (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && retain_initrd) {

[Severity: High]
Since retain_initrd is initialized to false at the start of setup_resources()
and hasn't been modified before this check, will this condition always
evaluate to false?

It looks like this block is completely unreachable, which would prevent the
initrd resource from being populated or registered.

> +		unsigned long initrd_addr, initrd_size;
> +	
> +		if (strstr(boot_command_line, "retain_initrd"))

[Severity: Medium]
If the unreachable code issue above is addressed, is there a risk that using
strstr() will incorrectly match strings like "retain_initrd=0"?

The generic kernel code in init/initramfs.c interprets "retain_initrd=0" as
disabled and frees the initrd memory back to the buddy allocator. If this
string match catches "retain_initrd=0", would we end up registering freed
memory as an IORESOURCE_BUSY initrd resource? 

This mismatch could mislead userspace tools about system RAM availability.

> +			retain_initrd = true;
> +		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;
> +		}
> +	}

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

      reply	other threads:[~2026-08-18 16:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 16:39 [PATCH v3] s390/iomem: register initrd as an iomem resource when retain_initrd is set Joseph Cathcart
2026-08-18 16:48 ` sashiko-bot [this message]

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=20260818164807.34E201F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=josephc@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.