From: Ionut Nechita <ionut.nechita@windriver.com>

Hi,

The x86 crash code sizes the elfcorehdr reservation with
CONFIG_NR_CPUS_DEFAULT, which is a Kconfig default and not an upper
bound.  The header itself carries one phdr per possible CPU, so the
reservation is too small whenever NR_CPUS exceeds NR_CPUS_DEFAULT.

Patch 1 sizes it with CONFIG_NR_CPUS instead.  Patch 2 fixes the two
comments that still name NR_CPUS_DEFAULT.

Based on linux-next (next-20260826, base-commit f82a5da2f0496).

Changes since v3:
- Patch 1/2: cut the changelog down to what Dave Hansen suggested.  I
  kept one sentence he had dropped - that kexec_file_load(2) fails with
  -EINVAL - because that is the failure this was reported for and what
  the Fixes: tag addresses; the silent kexec_load(2) truncation is the
  other half.  Happy to trim further if that is still too much.
- Patch 2/2: changelog trimmed the same way.
- No code changes; the diff is byte-identical to v2 and v3.
- Rebased from next-20260825 onto next-20260826.

Reviewers: the code has not moved since v2, so I carried the tags again.

Reproducer, for the archive - single-socket Xeon 6776P, PREEMPT_RT, with
CONFIG_NR_CPUS_DEFAULT=64, CONFIG_NR_CPUS=256, CONFIG_MAXSMP and
CONFIG_MEMORY_HOTPLUG off, CONFIG_CRASH_MAX_MEMORY_RANGES=8192:

- 144 possible CPUs: the buffer overshoots the reservation by
  (144 - 64) * 56 = 4480 bytes, more than the 4096 bytes of page
  padding, and 'kexec -p -s' fails with
  "kexec_file_load failed: Invalid argument"
- 72 possible CPUs (reduced via firmware): the overshoot is
  (72 - 64) * 56 = 448 bytes, still absorbed by the page rounding, and
  the load succeeds

The two follow-ups Sourabh Jain raised on the v2 thread - the
add_segment_phys_virt() bufsz truncation in kexec-tools, and having
crash_load_segments() skip the kbuf.memsz update when the prepared
buffer is already larger - are still deliberately out of scope here.

v1: https://lore.kernel.org/lkml/20260812170433.533845-1-ionut.nechita@windriver.com/
v2: https://lore.kernel.org/lkml/20260825075043.42041-1-ionut.nechita@windriver.com/
v3: https://lore.kernel.org/lkml/20260826073527.21487-1-ionut.nechita@windriver.com/

Ionut Nechita (2):
  x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not
    CONFIG_NR_CPUS_DEFAULT
  crash: update stale NR_CPUS_DEFAULT references in elfcorehdr sizing
    docs

 arch/x86/kernel/crash.c | 6 +++---
 kernel/Kconfig.kexec    | 2 +-
 kernel/crash_core.c     | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)


base-commit: f82a5da2f04960df9fb57489992d03dd5e64ec6f
--
2.55.0

On 27 August 2026 08:08:20 BST, "Ionut Nechita (Wind River)"
<ionut.nechita@windriver.com> wrote:
>From: Ionut Nechita <ionut.nechita@windriver.com>
>
>Hi,
>
>The x86 crash code sizes the elfcorehdr reservation with
>CONFIG_NR_CPUS_DEFAULT, which is a Kconfig default and not an upper
>bound.  The header itself carries one phdr per possible CPU, so the
>reservation is too small whenever NR_CPUS exceeds NR_CPUS_DEFAULT.
>
>Patch 1 sizes it with CONFIG_NR_CPUS instead.  Patch 2 fixes the two
>comments that still name NR_CPUS_DEFAULT.
>
>Based on linux-next (next-20260826, base-commit f82a5da2f0496).
>
>Changes since v3:
>- Patch 1/2: cut the changelog down to what Dave Hansen suggested.  I
>  kept one sentence he had dropped - that kexec_file_load(2) fails with
>  -EINVAL - because that is the failure this was reported for and what
>  the Fixes: tag addresses; the silent kexec_load(2) truncation is the
>  other half.  Happy to trim further if that is still too much.
>- Patch 2/2: changelog trimmed the same way.
>- No code changes; the diff is byte-identical to v2 and v3.
>- Rebased from next-20260825 onto next-20260826.
>
>Reviewers: the code has not moved since v2, so I carried the tags again.
>
>Reproducer, for the archive - single-socket Xeon 6776P, PREEMPT_RT, with
>CONFIG_NR_CPUS_DEFAULT=64, CONFIG_NR_CPUS=256, CONFIG_MAXSMP and
>CONFIG_MEMORY_HOTPLUG off, CONFIG_CRASH_MAX_MEMORY_RANGES=8192:
>
>- 144 possible CPUs: the buffer overshoots the reservation by
>  (144 - 64) * 56 = 4480 bytes, more than the 4096 bytes of page
>  padding, and 'kexec -p -s' fails with
>  "kexec_file_load failed: Invalid argument"
>- 72 possible CPUs (reduced via firmware): the overshoot is
>  (72 - 64) * 56 = 448 bytes, still absorbed by the page rounding, and
>  the load succeeds
>
>The two follow-ups Sourabh Jain raised on the v2 thread - the
>add_segment_phys_virt() bufsz truncation in kexec-tools, and having
>crash_load_segments() skip the kbuf.memsz update when the prepared
>buffer is already larger - are still deliberately out of scope here.
>
>v1: https://lore.kernel.org/lkml/20260812170433.533845-1-ionut.nechita@windriver.com/
>v2: https://lore.kernel.org/lkml/20260825075043.42041-1-ionut.nechita@windriver.com/
>v3: https://lore.kernel.org/lkml/20260826073527.21487-1-ionut.nechita@windriver.com/
>
>Ionut Nechita (2):
>  x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not
>    CONFIG_NR_CPUS_DEFAULT
>  crash: update stale NR_CPUS_DEFAULT references in elfcorehdr sizing
>    docs
>
> arch/x86/kernel/crash.c | 6 +++---
> kernel/Kconfig.kexec    | 2 +-
> kernel/crash_core.c     | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
>
>base-commit: f82a5da2f04960df9fb57489992d03dd5e64ec6f
>--
>2.55.0
>
>
>
Mergers, could you use my new email (brads@mainlining.org) instead of my
old one
(include@grrlz.net) for This?
--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/