From: Dave Hansen <dave.hansen@intel.com>
To: "Ionut Nechita (Wind River)" <ionut.nechita@windriver.com>,
x86@kernel.org, kexec@lists.infradead.org
Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com,
akpm@linux-foundation.org, baoquan.he@linux.dev, rppt@kernel.org,
pasha.tatashin@soleen.com, pratyush@kernel.org,
ruirui.yang@linux.dev, eric.devolder@oracle.com,
hbathini@linux.ibm.com, sourabhjain@linux.ibm.com,
ruanjinjie@huawei.com, include@grrlz.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT
Date: Wed, 26 Aug 2026 06:33:23 -0700 [thread overview]
Message-ID: <33cf028a-58c7-4ffd-af80-d689a67684c7@intel.com> (raw)
In-Reply-To: <20260826073527.21487-2-ionut.nechita@windriver.com>
On 8/26/26 00:35, Ionut Nechita (Wind River) wrote:
> Assisted-by: LLM
"LLM" went a little wild on the changelogs here. Shouldn't this just be
something like:
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 will undersize a reservation if NR_CPUS exceeds
NR_CPUS_DEFAULT. This causes kexec_load() silently truncate the
elfcorehdr, which surfaces later as a bad or unusable dump.
Size the elfcorehdr reservation with NR_CPUS instead.
---
Does it need more than that?
next prev parent reply other threads:[~2026-08-26 13:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 7:35 [PATCH v3 0/2] x86/crash: fix kexec_file_load(2) -EINVAL on machines with many possible CPUs Ionut Nechita (Wind River)
2026-08-26 7:35 ` [PATCH v3 1/2] x86/crash: reserve elfcorehdr for CONFIG_NR_CPUS, not CONFIG_NR_CPUS_DEFAULT Ionut Nechita (Wind River)
2026-08-26 13:33 ` Dave Hansen [this message]
2026-08-26 7:35 ` [PATCH v3 2/2] crash: update stale NR_CPUS_DEFAULT references in elfcorehdr sizing docs Ionut Nechita (Wind River)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33cf028a-58c7-4ffd-af80-d689a67684c7@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=eric.devolder@oracle.com \
--cc=hbathini@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=include@grrlz.net \
--cc=ionut.nechita@windriver.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=ruirui.yang@linux.dev \
--cc=sourabhjain@linux.ibm.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.