[PATCH 0/1] x86/crash: fix kexec_file_load(2) -EINVAL on machines with many possible CPUs

[Ionut Nechita (Wind River)]

From: Ionut Nechita <ionut.nechita@xxxxxxxxxxxxx>

Hi,

On x86 with CONFIG_CRASH_HOTPLUG=y, the crash elfcorehdr segment is
reserved (memsz) based on CONFIG_NR_CPUS_DEFAULT, while the header that
is actually built carries one PT_NOTE per possible CPU (bounded by
CONFIG_NR_CPUS).  When num_possible_cpus() exceeds CONFIG_NR_CPUS_DEFAULT
- which happens on configs that raise CONFIG_NR_CPUS above the arch
default without MAXSMP - the header outgrows its page-aligned
reservation and kexec_file_load(2) is rejected by
sanity_check_segment_list() with -EINVAL.  The classic kexec_load(2)
path is unaffected because user space builds the elfcorehdr without the
hotplug over-allocation.

This single patch reserves the elfcorehdr for CONFIG_NR_CPUS, the
compile-time upper bound of num_possible_cpus(), so the reservation
always covers the header that is actually generated.

Based on linux-next (next-20260811, base-commit 5e6de6a2b522f).

Verified on a single-socket Xeon 6776P running a PREEMPT_RT kernel with:

	# CONFIG_MAXSMP is not set
	CONFIG_NR_CPUS_RANGE_BEGIN=2
	CONFIG_NR_CPUS_RANGE_END=512
	CONFIG_NR_CPUS_DEFAULT=64
	CONFIG_NR_CPUS=256

- 144 possible CPUs: 'kexec -p -s' fails with
  "kexec_file_load failed: Invalid argument"
- 72 possible CPUs (reduced via firmware): succeeds

Ionut Nechita (1):
  x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not
    CONFIG_NR_CPUS_DEFAULT

 arch/x86/kernel/crash.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

base-commit: 5e6de6a2b522f
-- 
2.43.0