public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] of: fdt: skip KHO when booting as crash kernel
@ 2026-04-07 15:06 Evangelos Petrongonas
  2026-04-09 14:22 ` Mike Rapoport
  0 siblings, 1 reply; 2+ messages in thread
From: Evangelos Petrongonas @ 2026-04-07 15:06 UTC (permalink / raw)
  To: Rob Herring, Saravana Kannan
  Cc: Evangelos Petrongonas, Mike Rapoport (Microsoft), Changyuan Lyu,
	Alexander Graf, Pasha Tatashin, Pratyush Yadav, Andrew Morton,
	devicetree, kexec, linux-kernel, nh-open-source

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


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] of: fdt: skip KHO when booting as crash kernel
  2026-04-07 15:06 [PATCH] of: fdt: skip KHO when booting as crash kernel Evangelos Petrongonas
@ 2026-04-09 14:22 ` Mike Rapoport
  0 siblings, 0 replies; 2+ messages in thread
From: Mike Rapoport @ 2026-04-09 14:22 UTC (permalink / raw)
  To: Evangelos Petrongonas
  Cc: Rob Herring, Saravana Kannan, Changyuan Lyu, Alexander Graf,
	Pasha Tatashin, Pratyush Yadav, Andrew Morton, devicetree, kexec,
	linux-kernel, nh-open-source

Hi Evangelos,

On Tue, Apr 07, 2026 at 03:06:33PM +0000, Evangelos Petrongonas wrote:
> 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(-)

What about x86? ;-)
 
> 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;
> +

This seems redundant if don't add KHO nodes at the first place.

>  	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;

kho_add_chosen() bails out if there's no KHO buffer in kimage, so if
kho_fill_kimage won't add KHO buffer to kexec_crash_image it should be
enough.

> -- 
> 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
> 

-- 
Sincerely yours,
Mike.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-04-09 14:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-07 15:06 [PATCH] of: fdt: skip KHO when booting as crash kernel Evangelos Petrongonas
2026-04-09 14:22 ` Mike Rapoport

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox