Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] kho: do not reserve scratch memory in the kdump kernel
@ 2026-08-03 19:39 Maxi Saparov
  2026-08-10  8:23 ` Mike Rapoport
  0 siblings, 1 reply; 2+ messages in thread
From: Maxi Saparov @ 2026-08-03 19:39 UTC (permalink / raw)
  To: Mike Rapoport, Pasha Tatashin, Pratyush Yadav
  Cc: Alexander Graf, Evangelos Petrongonas, kexec, linux-mm,
	linux-kernel, sdimitropoulos, Maxi Saparov, stable

From: Maxi Saparov <masaparov@coreweave.com>

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 function computes the sizes from the early
memblock reservations of the kernel. The default scratch_scale is
200%. The lowmem and global scratch areas each get twice the size of
the early reservations. Each NUMA node gets one more scratch area at
the same scale.

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. Disable KHO in the kdump kernel
so that it does not reserve scratch memory.

Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
Cc: stable@vger.kernel.org
Signed-off-by: Maxi Saparov <masaparov@coreweave.com>
---
 kernel/liveupdate/kexec_handover.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 6fad9152387a..53b59edb5b36 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -12,6 +12,7 @@
 
 #include <linux/cleanup.h>
 #include <linux/cma.h>
+#include <linux/crash_dump.h>
 #include <linux/kmemleak.h>
 #include <linux/count_zeros.h>
 #include <linux/kasan.h>
@@ -1636,6 +1637,9 @@ void __init kho_memory_init(void)
 
 		if (kho_mem_retrieve(kho_get_fdt()))
 			kho_in.fdt_phys = 0;
+	} else if (is_kdump_kernel()) {
+		kho_enable = false;
+		pr_info("disabled in the kdump kernel\n");
 	} else {
 		kho_reserve_scratch();
 	}

base-commit: 3a0b8fa2eb36afc88b62a95f33f0c77c71fa5ded
-- 
2.55.0



^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] kho: do not reserve scratch memory in the kdump kernel
  2026-08-03 19:39 [PATCH] kho: do not reserve scratch memory in the kdump kernel Maxi Saparov
@ 2026-08-10  8:23 ` Mike Rapoport
  0 siblings, 0 replies; 2+ messages in thread
From: Mike Rapoport @ 2026-08-10  8:23 UTC (permalink / raw)
  To: Maxi Saparov
  Cc: Pasha Tatashin, Pratyush Yadav, Alexander Graf,
	Evangelos Petrongonas, kexec, linux-mm, linux-kernel,
	sdimitropoulos, Maxi Saparov, stable

Hi,

On Mon, Aug 03, 2026 at 03:39:38PM -0400, Maxi Saparov wrote:
> From: Maxi Saparov <masaparov@coreweave.com>
> 
> 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 function computes the sizes from the early
> memblock reservations of the kernel. The default scratch_scale is
> 200%. The lowmem and global scratch areas each get twice the size of
> the early reservations. Each NUMA node gets one more scratch area at
> the same scale.
> 
> 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. Disable KHO in the kdump kernel
> so that it does not reserve scratch memory.
> 
> Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Maxi Saparov <masaparov@coreweave.com>
> ---
>  kernel/liveupdate/kexec_handover.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 6fad9152387a..53b59edb5b36 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -12,6 +12,7 @@
>  
>  #include <linux/cleanup.h>
>  #include <linux/cma.h>
> +#include <linux/crash_dump.h>
>  #include <linux/kmemleak.h>
>  #include <linux/count_zeros.h>
>  #include <linux/kasan.h>
> @@ -1636,6 +1637,9 @@ void __init kho_memory_init(void)
>  
>  		if (kho_mem_retrieve(kho_get_fdt()))
>  			kho_in.fdt_phys = 0;
> +	} else if (is_kdump_kernel()) {
> +		kho_enable = false;
> +		pr_info("disabled in the kdump kernel\n");

Can we put this on top as a separate if, like

	if (is_kdump_kernel()) {
		/* disable KHO */
		return;
	}

>  	} else {
>  		kho_reserve_scratch();
>  	}
> 
> base-commit: 3a0b8fa2eb36afc88b62a95f33f0c77c71fa5ded
> -- 
> 2.55.0
> 

-- 
Sincerely yours,
Mike.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-08-10  8:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-03 19:39 [PATCH] kho: do not reserve scratch memory in the kdump kernel Maxi Saparov
2026-08-10  8:23 ` Mike Rapoport

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox