From: Pratyush Yadav <pratyush@kernel.org>
To: George Guo <dongtai.guo@linux.dev>
Cc: chenhuacai@kernel.org, rppt@kernel.org,
pasha.tatashin@soleen.com, pratyush@kernel.org,
kernel@xen0n.name, graf@amazon.com, shuah@kernel.org,
loongarch@lists.linux.dev, kexec@lists.infradead.org,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, George Guo <guodongtai@kylinos.cn>
Subject: Re: [PATCH 2/7] LoongArch: kho: strip stale kho_handover= from reused cmdline
Date: Mon, 25 May 2026 19:49:28 +0200 [thread overview]
Message-ID: <2vxzpl2j5qhj.fsf@kernel.org> (raw)
In-Reply-To: <20260525062810.103367-3-dongtai.guo@linux.dev> (George Guo's message of "Mon, 25 May 2026 14:28:05 +0800")
On Mon, May 25 2026, George Guo wrote:
> From: George Guo <guodongtai@kylinos.cn>
>
> When kexec is invoked with --reuse-cmdline after a liveupdate boot, the
> running kernel's command line already contains a kho_handover= parameter
> from the previous kexec load. load_other_segments() prepends a fresh
> kho_handover= for the new handover FDT but then appends the original
> cmdline verbatim, resulting in two kho_handover= entries:
>
> kho_handover=0x4000@<new_fdt>,... kho_handover=0x4000@<stale_fdt>,...
>
> early_param() calls early_parse_kho() for each occurrence in order, so
> kho_populate() is invoked twice and the second call overwrites the first
> with the stale FDT address. The stale address no longer holds a valid
> KHO FDT, causing __kho_radix_walk_tree() to dereference a garbage
> pointer and panic early in mm_core_init().
>
> Fix this by adding the new kho_handover= to the cmdline prefix first,
> then stripping any stale kho_handover= tokens from the appended original
> cmdline portion, so only the freshly generated entry survives.
>
> Signed-off-by: George Guo <guodongtai@kylinos.cn>
> ---
> arch/loongarch/kernel/machine_kexec_file.c | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
> index ddf4d0e0e7fd..ffaedd055e62 100644
> --- a/arch/loongarch/kernel/machine_kexec_file.c
> +++ b/arch/loongarch/kernel/machine_kexec_file.c
> @@ -71,6 +71,37 @@ static void cmdline_add_kho(struct kimage *image, unsigned long *cmdline_tmplen,
> image->kho.scratch->bufsz, (u64)image->kho.scratch->mem);
> *cmdline_tmplen += n;
> }
> +
> +/*
> + * Remove all "kho_handover=..." tokens from cmdline. Needed when
> + * --reuse-cmdline is used: the running kernel's cmdline already carries a
> + * stale kho_handover= from the previous kexec load; without removal the new
> + * kernel sees two entries and kho_populate() ends up using the wrong (stale)
> + * FDT address.
> + */
> +static void cmdline_remove_kho(char *cmdline)
> +{
> + const char *key = "kho_handover=";
> + size_t key_len = strlen(key);
> + char *p = cmdline;
> +
> + while ((p = strstr(p, key)) != NULL) {
> + char *start = p;
> + char *end;
> +
> + /* Only match at a token boundary */
> + if (start != cmdline && *(start - 1) != ' ') {
> + p += key_len;
> + continue;
> + }
> + end = start + key_len;
> + while (*end && *end != ' ')
> + end++;
> + while (*end == ' ')
> + end++;
> + memmove(start, end, strlen(end) + 1);
> + }
> +}
Ugh, modifying the commandline supplied by userspace feels odd... Can
you at all do this via device tree?
If not, would it make more sense to reject kexec_load if command line
has kho_handover= and teach kexec-tools to strip it on its side?
> #endif
>
> #ifdef CONFIG_CRASH_DUMP
> @@ -249,6 +280,10 @@ int load_other_segments(struct kimage *image,
> }
>
> memcpy(modified_cmdline + cmdline_tmplen, cmdline, cmdline_len);
> +#ifdef CONFIG_KEXEC_HANDOVER
> + /* Strip stale kho_handover= that --reuse-cmdline may have carried over */
> + cmdline_remove_kho(modified_cmdline + cmdline_tmplen);
> +#endif
> cmdline = modified_cmdline;
> image->arch.cmdline_ptr = (unsigned long)cmdline;
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-05-25 17:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 6:28 [PATCH 0/7] LoongArch: add KHO support and selftests George Guo
2026-05-25 6:28 ` [PATCH 1/7] LoongArch: Add KHO basic support George Guo
2026-05-25 17:34 ` Pratyush Yadav
2026-05-25 6:28 ` [PATCH 2/7] LoongArch: kho: strip stale kho_handover= from reused cmdline George Guo
2026-05-25 17:49 ` Pratyush Yadav [this message]
2026-05-25 6:28 ` [PATCH 3/7] LoongArch: Add missing linux/mm.h include in asm/io.h George Guo
2026-05-25 6:28 ` [PATCH 4/7] LoongArch: kexec: avoid overwriting QEMU's machine FDT at 0x100000 George Guo
2026-05-25 6:28 ` [PATCH 5/7] selftests/kho: add LoongArch vmtest support George Guo
2026-05-25 6:28 ` [PATCH 6/7] selftests/kho: LoongArch: disable PS/2 input devices for QEMU virt George Guo
2026-05-25 6:28 ` [PATCH 7/7] selftests/kho: handle QEMU not exiting after kexec on LoongArch George Guo
2026-05-25 7:48 ` Mike Rapoport
2026-05-25 7:48 ` [PATCH 0/7] LoongArch: add KHO support and selftests Mike Rapoport
2026-05-25 10:25 ` Huacai Chen
2026-05-25 11:24 ` Mike Rapoport
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=2vxzpl2j5qhj.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=chenhuacai@kernel.org \
--cc=dongtai.guo@linux.dev \
--cc=graf@amazon.com \
--cc=guodongtai@kylinos.cn \
--cc=kernel@xen0n.name \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=loongarch@lists.linux.dev \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=shuah@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