From: Evangelos Petrongonas <epetron@amazon.de>
To: Rob Herring <robh@kernel.org>, Saravana Kannan <saravanak@kernel.org>
Cc: Evangelos Petrongonas <epetron@amazon.de>,
"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
Changyuan Lyu <changyuanl@google.com>,
Alexander Graf <graf@amazon.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
<devicetree@vger.kernel.org>, <kexec@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <nh-open-source@amazon.com>
Subject: [PATCH] of: fdt: skip KHO when booting as crash kernel
Date: Tue, 7 Apr 2026 15:06:33 +0000 [thread overview]
Message-ID: <20260407150639.69923-1-epetron@amazon.de> (raw)
KHO preserves state across kexec by passing a KHO-specific FDT pointer
and scratch memory region to the incoming kernel. These point to
physical addresses in the outgoing kernel's memory that the incoming
kernel is expected to access and restore from. This falls apart when
the incoming kernel is a crash kernel as the crash kernel can run in a
small reserved memory region. The scratch regions can sit outside this
reservation, so the end result is quite unpleasant.
kho_add_chosen() unconditionally propagates KHO properties into
the device tree for all kexec image types, including crash images. The
crash kernel then discovers these properties during
early_init_dt_check_kho(), records the stale physical addresses via
kho_populate(), and later faults in kho_memory_init() when it tries
phys_to_virt() on the KHO FDT address:
Unable to handle kernel paging request at virtual address xxxxxxxx
...
fdt_offset_ptr+...
fdt_check_node_offset_+...
fdt_first_property_offset+...
fdt_get_property_namelen_+...
fdt_getprop+...
kho_memory_init+...
mm_core_init+...
start_kernel+...
kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
images, but the DT property propagation and the consumer side were both
missing the same guard.
Fix this at both ends. Have kho_add_chosen() skip writing KHO properties
for crash images so the stale pointers never reach the crash kernel's
device tree. Also have early_init_dt_check_kho() bail out when
is_kdump_kernel() is true. This way even if KHO properties end up in
the DT through some other path, the crash kernel will not act on them.
Fixes: 274cdcb1c004 ("arm64: add KHO support")
Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
---
I think we should backport the fix on KHO compatible versions (6.16+),
hence the "Fixes:" tag. Tested on an arm64 system.
drivers/of/fdt.c | 3 +++
drivers/of/kexec.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 43a0944ca462..77018ec99fc8 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -926,6 +926,9 @@ static void __init early_init_dt_check_kho(void)
if (!IS_ENABLED(CONFIG_KEXEC_HANDOVER) || (long)node < 0)
return;
+ if (is_kdump_kernel())
+ return;
+
if (!of_flat_dt_get_addr_size(node, "linux,kho-fdt",
&fdt_start, &fdt_size))
return;
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index c4cf3552c018..b95f0b386684 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -271,7 +271,8 @@ static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node
if (ret && ret != -FDT_ERR_NOTFOUND)
return ret;
- if (!image->kho.fdt || !image->kho.scratch)
+ if (!image->kho.fdt || !image->kho.scratch ||
+ image->type == KEXEC_TYPE_CRASH)
return 0;
fdt_mem = image->kho.fdt;
--
2.43.0
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
reply other threads:[~2026-04-07 15:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260407150639.69923-1-epetron@amazon.de \
--to=epetron@amazon.de \
--cc=akpm@linux-foundation.org \
--cc=changyuanl@google.com \
--cc=devicetree@vger.kernel.org \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=saravanak@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