Re: [PATCH v2] kho: skip KHO for crash kernel

[Pratyush Yadav <pratyush@kernel.org>]

Hi Evangelos,

On Fri, Apr 10 2026, Evangelos Petrongonas wrote:

> kho_fill_kimage() unconditionally populates the kimage with KHO
> metadata for every kexec image type. When the image is a crash kernel,
> this can be problematic as the crash kernel can run in a small reserved
> region and the KHO scratch areas can sit outside it.
> The crash kernel then faults during 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 kho_fill_kimage() was missing the same guard. As
> kho_fill_kimage() is the single point that populates image->kho.fdt
> and image->kho.scratch, fixing it here is sufficient for both arm64
> and x86 as the FDT and boot_params path are bailing out when these
> fields are unset.
>
> Fixes: d7255959b69a ("kho: allow kexec load before KHO finalization")
> Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
> ---
>
> v2: Per Mike's review [1], move the guard into kho_fill_kimage() instead
>     of patching the arch-level producers and consumers. This fixes
>     both arm64 and x86 in one place and avoids redundant checks. Tested again.
>
> Note regarding backporting
> The offending commit was deployed with 6.19. The only other supported
> kernel version with 6.18, unless I miss someting uses
> ```
> if (!kho_out.finalized)
> ```
> which in the case of crash kernel it shouldn't be finalised.

While normally you should load the crash kernel early in boot and at
that point KHO should not be finalized, I don't see anything that
prevents crash kernel from being loaded after finalize. In which case,
you can trigger this bug before d7255959b69a ("kho: allow kexec load
before KHO finalization") as well. Also, before f322a97aeb2a ("kho: only
fill kimage if KHO is finalized") (landed in v6.18) kho_fill_kimage()
was also guarded by if (!kho_enable). So you'd hit this bug in all
kernels before that point in the very same way as today.

So should we update Fixes to 3bdecc3c93f9 ("kexec: add KHO support to
kexec file loads") and Cc stable?

>
> [1] https://lore.kernel.org/all/ade2ExpM8ROXV-vy@kernel.org/
>
>  kernel/liveupdate/kexec_handover.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index cc68a3692905..1029fe8778f2 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -1551,7 +1551,7 @@ int kho_fill_kimage(struct kimage *image)
>  	int err = 0;
>  	struct kexec_buf scratch;
>  
> -	if (!kho_enable)
> +	if (!kho_enable || image->type == KEXEC_TYPE_CRASH)
>  		return 0;
>  
>  	image->kho.fdt = virt_to_phys(kho_out.fdt);

-- 
Regards,
Pratyush Yadav