Re: [PATCH v2] kho: do not reserve scratch memory in the kdump kernel

[Mike Rapoport]

Hi,

Please don't send vN+1 as a reply to vN next time.

On Tue, Aug 11, 2026 at 12:18:57PM -0400, Maxi Saparov wrote:
> From: Maxi Saparov <masaparov@xxxxxxxxxxxxx>
> 
> If a kernel with CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=y (or kho=on)
> does not receive a handover FDT, it reserves KHO scratch memory in
> kho_reserve_scratch().
> 
> The kdump kernel always takes this path. Since commit a6715d7ec472
> ("kho: skip KHO for crash kernel"), the kernel does not add KHO
> metadata to the crash kimage. As a result, the kdump kernel never
> receives a handover FDT and always reserves scratch memory.
> 
> The kdump kernel boots in the small crashkernel= memory reservation.
> On our x86 hosts, the kernel and initramfs make approximately 176 MB
> of early reservations. The scratch areas then use approximately
> 650 MB more of the crashkernel memory. When a large early allocation
> fails, the kdump kernel panics:
> 
>   bio: can't create integrity buf pool
> 
> A kdump kernel has nothing to hand over: its only task is to dump the
> memory of the old kernel and reboot. Fix is to disable KHO at the top of
> kho_memory_init() so that the kdump kernel does not reserve scratch
> memory.
> 
> Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Maxi Saparov <masaparov@xxxxxxxxxxxxx>

I queued this patch for v7.4, it'll appear in the liveupdate tree after the
merge window.

> ---
> v2: Move the kdump check to the top of kho_memory_init() as an early return.
> v1: https://lore.kernel.org/all/20260803193938.8778-1-maxi.saparov@xxxxxxxxx/
> 
>  kernel/liveupdate/kexec_handover.c | 7 +++++++
>  1 file changed, 7 insertions(+)

-- 
Sincerely yours,
Mike.