Re: [PATCH] of: fdt: skip KHO when booting as crash kernel

[Mike Rapoport <rppt@kernel.org>]

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.