On Mon, Sep 28 2026, [email protected] 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 <[email protected]> > > 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
