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 AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
