[PATCH v5 0/2] x86/crash: size the elfcorehdr reservation with NR_CPUS

[PATCH v5 0/2] x86/crash: size the elfcorehdr reservation with NR_CPUS

[Ionut Nechita (Wind River)]

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-20260831, base-commit 89c07d98716a1).

Changes since v4:
- Bradley Morgan's tags now use his new address, brads@mainlining.org,
  as he asked on the v4 thread.  His change of address was announced
  from the old one in [1] and he says the mailmap patch is already out.
- Rebased from next-20260826 onto next-20260831.  No code changes; the
  diff is byte-identical to v2, v3 and v4.

[1] https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

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/
v4: https://lore.kernel.org/lkml/20260827070822.12651-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: 89c07d98716a13454ec3fd9f97689e812cc71bd4
--
2.55.0

[PATCH v5 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT

[Ionut Nechita (Wind River)]

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

NR_CPUS_DEFAULT is purely a Kconfig thing.  Its entire purpose in life is
to start NR_CPUS at a sane value.  There is precisely one (buggy)
reference to it outside of Kconfig in the whole kernel: the x86 crash
code.

That code undersizes the elfcorehdr reservation whenever NR_CPUS exceeds
NR_CPUS_DEFAULT, because the header carries one phdr per possible CPU and
num_possible_cpus() is bounded by NR_CPUS.  kexec_file_load(2) then fails
with -EINVAL from sanity_check_segment_list(), and kexec_load(2) silently
truncates the elfcorehdr, which surfaces later as a bad or unusable dump.

Size the elfcorehdr reservation with NR_CPUS instead.

Fixes: ea53ad9cf73b ("x86/crash: add x86 crash hotplug support")
Assisted-by: LLM
Signed-off-by: Ionut Nechita <ionut.nechita@windriver.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <baoquan.he@linux.dev>
---
 arch/x86/kernel/crash.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index e681ec9cf1dc..e6f23933a6df 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -369,9 +369,9 @@ int crash_load_segments(struct kimage *image)
 	 * maximum CPUs and maximum memory ranges.
 	 */
 	if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
-		pnum = 2 + CONFIG_NR_CPUS_DEFAULT + CONFIG_CRASH_MAX_MEMORY_RANGES;
+		pnum = 2 + CONFIG_NR_CPUS + CONFIG_CRASH_MAX_MEMORY_RANGES;
 	else
-		pnum += 2 + CONFIG_NR_CPUS_DEFAULT;
+		pnum += 2 + CONFIG_NR_CPUS;
 
 	if (pnum < (unsigned long)PN_XNUM) {
 		kbuf.memsz = pnum * sizeof(Elf64_Phdr);
@@ -430,7 +430,7 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
 	unsigned int sz;
 
 	/* kernel_map, VMCOREINFO and maximum CPUs */
-	sz = 2 + CONFIG_NR_CPUS_DEFAULT;
+	sz = 2 + CONFIG_NR_CPUS;
 	if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
 		sz += CONFIG_CRASH_MAX_MEMORY_RANGES;
 	sz *= sizeof(Elf64_Phdr);

base-commit: 89c07d98716a13454ec3fd9f97689e812cc71bd4
-- 
2.55.0

Re: [PATCH v5 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT

[Sourabh Jain]

Hello,

The below patch overrides the changes introduce here:
https://lore.kernel.org/all/20260826092541.3905933-13-ruanjinjie@huawei.com/

Can you please review the above patch instead?

- Sourabh Jain

On 01/09/26 12:40, Ionut Nechita (Wind River) wrote:
> From: Ionut Nechita <ionut.nechita@windriver.com>
>
> NR_CPUS_DEFAULT is purely a Kconfig thing.  Its entire purpose in life is
> to start NR_CPUS at a sane value.  There is precisely one (buggy)
> reference to it outside of Kconfig in the whole kernel: the x86 crash
> code.
>
> That code undersizes the elfcorehdr reservation whenever NR_CPUS exceeds
> NR_CPUS_DEFAULT, because the header carries one phdr per possible CPU and
> num_possible_cpus() is bounded by NR_CPUS.  kexec_file_load(2) then fails
> with -EINVAL from sanity_check_segment_list(), and kexec_load(2) silently
> truncates the elfcorehdr, which surfaces later as a bad or unusable dump.
>
> Size the elfcorehdr reservation with NR_CPUS instead.
>
> Fixes: ea53ad9cf73b ("x86/crash: add x86 crash hotplug support")
> Assisted-by: LLM
> Signed-off-by: Ionut Nechita <ionut.nechita@windriver.com>
> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
> Reviewed-by: Bradley Morgan <brads@mainlining.org>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <baoquan.he@linux.dev>
> ---
>   arch/x86/kernel/crash.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index e681ec9cf1dc..e6f23933a6df 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -369,9 +369,9 @@ int crash_load_segments(struct kimage *image)
>   	 * maximum CPUs and maximum memory ranges.
>   	 */
>   	if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
> -		pnum = 2 + CONFIG_NR_CPUS_DEFAULT + CONFIG_CRASH_MAX_MEMORY_RANGES;
> +		pnum = 2 + CONFIG_NR_CPUS + CONFIG_CRASH_MAX_MEMORY_RANGES;
>   	else
> -		pnum += 2 + CONFIG_NR_CPUS_DEFAULT;
> +		pnum += 2 + CONFIG_NR_CPUS;
>   
>   	if (pnum < (unsigned long)PN_XNUM) {
>   		kbuf.memsz = pnum * sizeof(Elf64_Phdr);
> @@ -430,7 +430,7 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
>   	unsigned int sz;
>   
>   	/* kernel_map, VMCOREINFO and maximum CPUs */
> -	sz = 2 + CONFIG_NR_CPUS_DEFAULT;
> +	sz = 2 + CONFIG_NR_CPUS;
>   	if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
>   		sz += CONFIG_CRASH_MAX_MEMORY_RANGES;
>   	sz *= sizeof(Elf64_Phdr);
>
> base-commit: 89c07d98716a13454ec3fd9f97689e812cc71bd4

Re: [PATCH v5 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT

[Dave Hansen]

On 9/1/26 00:10, Ionut Nechita (Wind River) wrote:
> Assisted-by: LLM

This seems a _bit_ opaque and imprecise. Could you take a quick look
through:

https://docs.kernel.org/process/generated-content.html

and try to err a bit more on the side of transparency for the next one?

Re: [PATCH v5 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT

[Bradley Morgan]

On 2 September 2026 22:24:16 BST, Dave Hansen <dave.hansen@intel.com>
wrote:
>On 9/1/26 00:10, Ionut Nechita (Wind River) wrote:
>> Assisted-by: LLM
>
>This seems a _bit_ opaque and imprecise. Could you take a quick look
>through:
>
>https://docs.kernel.org/process/generated-content.html
>
>and try to err a bit more on the side of transparency for the next one?


Spoiler: new rule added in the docs, you no longer need to do Provider:Modelname any longer


You only have to do

Assisted-by: LLM

Or

Assisted-by: (Let's say checkpatch --fix?)



--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

Re: [PATCH v5 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT

[Dave Hansen]

On 9/2/26 14:27, Bradley Morgan wrote:
> On 2 September 2026 22:24:16 BST, Dave Hansen <dave.hansen@intel.com>
> wrote:
>> On 9/1/26 00:10, Ionut Nechita (Wind River) wrote:
>>> Assisted-by: LLM
>> This seems a _bit_ opaque and imprecise. Could you take a quick look
>> through:
>>
>> https://docs.kernel.org/process/generated-content.html
>>
>> and try to err a bit more on the side of transparency for the next one?
> 
> Spoiler: new rule added in the docs, you no longer need to do Provider:Modelname any longer

I'm just saying, for me, "Assisted-by: LLM" is almost worthless. I'm not
going to go tilting at any windmills to get that doc changed, but it
seems a borderline waste of bytes.

Please just say how you used the tools. At least for things you want me
to merge. Yes, I owe an Documentation/process/maintainer-tip.rst update
for this.

Re: [PATCH v5 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT

[Bradley Morgan]

On 2 September 2026 22:34:09 BST, Dave Hansen <dave.hansen@intel.com>
wrote:
>On 9/2/26 14:27, Bradley Morgan wrote:
>> On 2 September 2026 22:24:16 BST, Dave Hansen <dave.hansen@intel.com>
>> wrote:
>>> On 9/1/26 00:10, Ionut Nechita (Wind River) wrote:
>>>> Assisted-by: LLM
>>> This seems a _bit_ opaque and imprecise. Could you take a quick look
>>> through:
>>>
>>> https://docs.kernel.org/process/generated-content.html
>>>
>>> and try to err a bit more on the side of transparency for the next one?
>> 
>> Spoiler: new rule added in the docs, you no longer need to do
>Provider:Modelname any longer
>
>I'm just saying, for me, "Assisted-by: LLM" is almost worthless. I'm not
>going to go tilting at any windmills to get that doc changed, but it
>seems a borderline waste of bytes.
>

True, people argued that nobody cared what extras you used, all they needed
to
know is what the base you used is. E.g: LLM

>Please just say how you used the tools. At least for things you want me
>to merge.

Maybe a --- line note could be good?

E.g:

(Patch)
---
I used a LLM (Claude code?) to (discover, build, etc?) the patch.

 Yes, I owe an Documentation/process/maintainer-tip.rst update
>for this.


Want me to do it? Or could you cc me

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/

[PATCH v5 2/2] crash: update stale NR_CPUS_DEFAULT references in elfcorehdr sizing docs

[Ionut Nechita (Wind River)]

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

The elfcorehdr reservation is now sized with NR_CPUS, but two comments
still name NR_CPUS_DEFAULT: the one above crash_handle_hotplug_event()
and the CRASH_MAX_MEMORY_RANGES help text.

Update both.  Documentation only, no functional change.

Suggested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Suggested-by: Bradley Morgan <brads@mainlining.org>
Assisted-by: LLM
Signed-off-by: Ionut Nechita <ionut.nechita@windriver.com>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
---
 kernel/Kconfig.kexec | 2 +-
 kernel/crash_core.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index 15632358bcf7..a97ed9605602 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -167,7 +167,7 @@ config CRASH_MAX_MEMORY_RANGES
 	  memory regions that the elfcorehdr buffer/segment can accommodate.
 	  These regions are obtained via walk_system_ram_res(); eg. the
 	  'System RAM' entries in /proc/iomem.
-	  This value is combined with NR_CPUS_DEFAULT and multiplied by
+	  This value is combined with NR_CPUS and multiplied by
 	  sizeof(Elf64_Phdr) to determine the final elfcorehdr memory buffer/
 	  segment size.
 	  The value 8192, for example, covers a (sparsely populated) 1TiB system
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 2b36aa9fade0..d0bd2d0cf899 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -648,7 +648,7 @@ int crash_check_hotplug_support(void)
  * new list of CPUs and memory. To make changes to the elfcorehdr, it
  * should be large enough to permit a growing number of CPU and Memory
  * resources. One can estimate the elfcorehdr memory size based on
- * NR_CPUS_DEFAULT and CRASH_MAX_MEMORY_RANGES. The elfcorehdr is
+ * NR_CPUS and CRASH_MAX_MEMORY_RANGES. The elfcorehdr is
  * excluded from SHA verification by default if the architecture
  * supports crash hotplug.
  */
-- 
2.55.0