Re: [PATCH v2] kho: do not reserve scratch memory in the kdump kernel
Mike Rapoport <[email protected]>
| Newsgroups | gmane.linux.kernel.stable,gmane.linux.kernel.kexec,gmane.linux.kernel.mm,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > > 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: [email protected] > Signed-off-by: Maxi Saparov <[email protected]> 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/[email protected]/ > > kernel/liveupdate/kexec_handover.c | 7 +++++++ > 1 file changed, 7 insertions(+) -- Sincerely yours, Mike.