Hi, On Tue, Dec 30, 2025 at 01:53:45PM +0800, Li Chen wrote: > With KHO enabled, the successor kernel can temporarily run memblock in > scratch-only mode during early boot. In that mode, SPARSEMEM may allocate > a per-node scratch buffer via sparse_buffer_init(map_count * > section_map_size()), which requires a single contiguous, aligned memblock > allocation. > > If the maximum usable scratch range in a node is smaller than the > estimated buffer size, kexec handover can hang very early in the > successor kernel, and we may even have no chance to see the error on > the console. > > Estimate the worst-case per-node requirement from the running kernel's > sparsemem layout and compare it against the reserved scratch list by > splitting scratch ranges per nid, sorting and merging them, and applying > the section_map_size() alignment constraint. Warn once when scratch > appears too small. > > This check is a heuristic based on the running kernel's sparsemem layout > and cannot account for all differences in a successor kernel. Keep it as > a warning instead of rejecting kexec loads to avoid false positives > causing unexpected regressions. Users can adjust kho_scratch accordingly > before attempting a handover. > > To reduce boot-time overhead(particularly on large NUMA servers), run > the check from a late initcall via system_long_wq instead of in > kho_reserve_scratch(). > > Signed-off-by: Li Chen <[email protected]> > --- > kernel/liveupdate/kexec_handover.c | 396 +++++++++++++++++++++++++++++ > 1 file changed, 396 insertions(+)
This is an overkill for something that a pr_err() or a panic() would be sufficient. -- Sincerely yours, Mike.
