Re: [PATCH v1 2/2] powerpc: add support for Kexec HandOver (KHO)

[Pratyush Yadav <pratyush@kernel.org>]

On Mon, Sep 28 2026, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] boot: late KHO initialization allows memblock to clobber preserved memory
> --
>
> commit 2f581dec390379323e7a0b4e4badb03487eea55f
> Author: Sourabh Jain <sourabhjain@linux.ibm.com>
>
> powerpc: add support for Kexec HandOver (KHO)
>
> Add architecture bits to enable CONFIG_KEXEC_HANDOVER on powerpc. This
> patch checks for KHO information in the device tree before unflattening it,
> allowing a kernel booted via KHO kexec to recover the FDT and scratch region.
> It also moves early_init_dt_check_kho() to be called from setup_arch().
>
>> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
>> index 4afaba19b5867..53c2f1897bfe1 100644
>> --- a/arch/powerpc/kernel/setup-common.c
>> +++ b/arch/powerpc/kernel/setup-common.c
>> @@ -923,6 +923,8 @@ void __init setup_arch(char **cmdline_p)
>>  	/* Set a half-reasonable default so udelay does something sensible */
>>  	loops_per_jiffy = 500000000 / HZ;
>>  
>> +	early_init_dt_check_kho();
>> +
>>  	/* Unflatten the device-tree passed by prom_init or kexec */
>>  	unflatten_device_tree();
>
> [Severity: High]
> Does calling early_init_dt_check_kho() in setup_arch() happen too late to
> protect against early memblock allocations clobbering preserved KHO memory?
>
> The Kexec HandOver (KHO) mechanism uses a scratch memory region to strictly
> confine early boot memory allocations in the successor kernel. This prevents
> them from overwriting memory pages preserved by the previous kernel, and is
> enforced when kho_populate() invokes memblock_set_kho_scratch_only().
>
> However, setup_arch() is invoked from start_kernel() long after early_setup()
> completes. During early_setup(), substantial dynamic memblock allocations occur
> before KHO scratch memory confinement is enforced.
>
> For example, move_device_tree() allocates memory for the FDT:
>
> arch/powerpc/kernel/prom.c:move_device_tree() {
> 	...
> 	p = memblock_alloc_raw(size, PAGE_SIZE);
> 	...
> }
>
> This is called via early_init_devtree() from early_setup():
>
> arch/powerpc/kernel/setup_64.c:early_setup() {
> 	...
> 	early_init_devtree(__va(dt_ptr));
>
> 	allocate_paca_ptrs();
> 	allocate_paca(boot_cpuid);
> 	... 
> 	early_init_mmu();
> 	...
> }
>
> Because KHO scratch-only mode has not yet been enforced during these early
> allocations, could they use standard memblock policies and overwrite preserved
> KHO memory state, corrupting the handover?

Sashiko seems to have a point. early_init_devtree() (called from
early_setup()) already does a lot of initialization that x86's
setup_arch() does, including making memblock allocations, allowing
resize, etc.

So perhaps you need to move this early_init_dt_check_kho() call to
early_setup()?

-- 
Regards,
Pratyush Yadav