From: Wandun <chenwandun1@gmail.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
chenhuacai@kernel.org, kernel@xen0n.name, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
saravanak@kernel.org, akpm@linux-foundation.org,
pasha.tatashin@soleen.com, pratyush@kernel.org,
ruirui.yang@linux.dev, robin.murphy@arm.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
kexec@lists.infradead.org, linux-mm@kvack.org,
iommu@lists.linux.dev, robh@kernel.org, baoquan.he@linux.dev,
rppt@kernel.org, m.szyprowski@samsung.com
Subject: Re: [PATCH v9 3/8] crash_core: serialize crash header preparation against hotplug
Date: Thu, 22 Oct 2026 15:44:48 +0800 [thread overview]
Message-ID: <098ff899-81b9-4ccc-a143-1e324446258f@gmail.com> (raw)
In-Reply-To: <31d63208-3ef2-420f-a0c2-d9d6d49c5e21@huawei.com>
On 10/22/26 10:00, Jinjie Ruan wrote:
>
>
> 在 2026/10/21 17:48, Wandun 写道:
>>
>>
>> On 10/21/26 17:13, Jinjie Ruan wrote:
>>>
>>>
>>> 在 2026/10/21 16:30, Wandun Chen 写道:
>>>> From: Wandun Chen <chenwandun@lixiang.com>
>>>>
>>>> crash_prepare_headers() counts memory ranges before populating the
>>>> allocated crash_mem array. The weak implementation used by ARM64,
>>>> RISC-V and LoongArch walks memblock.memory, while x86 performs the same
>>>> two-pass operation over system RAM resources. Concurrent memory hotplug
>>>> can change range source between the two walks and make the populate
>>>> pass overflow cmem->ranges.
>>>>
>>>> Take device_hotplug_lock when preparing crash headers during
>>>> kexec_file_load(). The x86/riscv memory hotplug path already takes
>>>> device_hotplug_lock, so call __crash_prepare_headers() directly
>>>> to avoid recursive locking.
>>>>
>>>> Sashiko reported this issue in [1].
>>>>
>>>> Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support")
>>>> Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file")
>>>> Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic")
>>>> Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
>>>> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
>>>> Link: https://sashiko.dev/#/message/20260806101002.1F84E1F000E9@smtp.kernel.org [1]
>>>> Acked-by: Baoquan He <baoquan.he@linux.dev>
>>>> ---
>>>> arch/riscv/kernel/crash.c | 2 +-
>>>> arch/x86/kernel/crash.c | 2 +-
>>>> include/linux/crash_core.h | 2 ++
>>>> kernel/crash_core.c | 17 +++++++++++++++--
>>>> 4 files changed, 19 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/riscv/kernel/crash.c b/arch/riscv/kernel/crash.c
>>>> index fe5a4b306aae..ac8df2edf2a7 100644
>>>> --- a/arch/riscv/kernel/crash.c
>>>> +++ b/arch/riscv/kernel/crash.c
>>>> @@ -70,7 +70,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
>>>> * Create the new elfcorehdr reflecting the changes to CPU and/or
>>>> * memory resources.
>>>> */
>>>> - if (crash_prepare_headers(true, &elfbuf, &elfsz, NULL)) {
>>>> + if (__crash_prepare_headers(true, &elfbuf, &elfsz, NULL)) {
>>>> pr_err("unable to create new elfcorehdr");
>>>> goto out;
>>>> }
>>>> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
>>>> index e6f23933a6df..bef008a0cb22 100644
>>>> --- a/arch/x86/kernel/crash.c
>>>> +++ b/arch/x86/kernel/crash.c
>>>> @@ -465,7 +465,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
>>>> * Create the new elfcorehdr reflecting the changes to CPU and/or
>>>> * memory resources.
>>>> */
>>>> - if (crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NULL)) {
>>>> + if (__crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NULL)) {
>>>> pr_err("unable to create new elfcorehdr");
>>>> goto out;
>>>> }
>>>> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
>>>> index bc087124cd78..28e7a81cf263 100644
>>>> --- a/include/linux/crash_core.h
>>>> +++ b/include/linux/crash_core.h
>>>> @@ -61,6 +61,8 @@ extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_ma
>>>> void **addr, unsigned long *sz);
>>>> extern int crash_prepare_headers(int need_kernel_map, void **addr,
>>>> unsigned long *sz, unsigned long *nr_mem_ranges);
>>>> +int __crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
>>>> + unsigned long *nr_mem_ranges);
>>>> extern int crash_exclude_core_ranges(struct crash_mem **cmem);
>>>>
>>>> struct kimage;
>>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>>>> index faa0f22dbb41..8a861a946e26 100644
>>>> --- a/kernel/crash_core.c
>>>> +++ b/kernel/crash_core.c
>>>> @@ -16,6 +16,7 @@
>>>> #include <linux/mm.h>
>>>> #include <linux/cpuhotplug.h>
>>>> #include <linux/memblock.h>
>>>> +#include <linux/device.h>
>>>> #include <linux/kmemleak.h>
>>>> #include <linux/crash_core.h>
>>>> #include <linux/reboot.h>
>>>> @@ -344,8 +345,8 @@ int crash_exclude_core_ranges(struct crash_mem **cmem)
>>>> return 0;
>>>> }
>>>>
>>>> -int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
>>>> - unsigned long *nr_mem_ranges)
>>>> +int __crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
>>>> + unsigned long *nr_mem_ranges)
>>>> {
>>>> unsigned int max_nr_ranges;
>>>> struct crash_mem *cmem;
>>>> @@ -382,6 +383,18 @@ int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
>>>> return ret;
>>>> }
>>>>
>>>> +int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
>>>> + unsigned long *nr_mem_ranges)
>>>> +{
>>>> + int ret;
>>>> +
>>>> + lock_device_hotplug();
>>>> + ret = __crash_prepare_headers(need_kernel_map, addr, sz, nr_mem_ranges);
>>>> + unlock_device_hotplug();
>>>
>>> I think this patch conflicts with my changes and would also conflict
>>> with the implementation of arm64 crash hotplug.
>>>
>>> https://lore.kernel.org/all/20260921090450.807575-15-ruanjinjie@huawei.com/
>>>
>> Have these patches already been merged? My current work is based on the latest
>> linux-next. If they have already been merged into the maintainer's branch,
>> please let me know, I will update my tree and rebase/re-adapt my changes accordingly.
>>
>>
>> Also, regarding the changes in kernel/crash_core.c: it looks like we modified
>> the same spot, the change is not wrong, is that right?
>
> Hi Wandun,
>
> However, I think someone should have informed me in advance; otherwise,
> doing duplicate fix work is pointless.
>
> I see that part of your patch series modifies code I previously changed,
> but I was not CC'd.
Hi Jinjie,
Sorry for not CC'ing you. I keep the per-patch Cc lists short because
large recipient sets have caused my sends to be cut off midway before,
(I'm still trying to track down exactly where the problem is) you should
have been on the list that's my miss. You'll be on the Cc of every future
version.
>
>>
>>> arm64 crash hotplug:
>>> https://lore.kernel.org/all/20260918100442.3841135-18-ruanjinjie@huawei.com/
>>
>> In addition, if arm64 gains crash hotplug support, the code there would indeed
>> need to be modified (to avoid a deadlock). As of now, arm64 crash hotplug
>> support has not been merged yet either, has it? I just want to make sure I
>> haven't missed anything.
>
> Yes, you are right. If your patch series will be merged soon, I will
> develop based on it.
Also thanks for your reminder, otherwise I might later overlook the case
where arm64 has already gained crash hotplug support, and introduce bugs
as a result.
Best regards,
Wandun>
>>
>>>
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> /**
>>>> * crash_exclude_mem_range - exclude a mem range for existing ranges
>>>> * @mem: mem->range contains an array of ranges sorted in ascending order
>>>
>>
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-10-22 7:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 8:30 [PATCH v9 0/8] kdump: reduce vmcore size and capture time Wandun Chen
2026-10-21 8:30 ` [PATCH v9 1/8] riscv: build crash_mem ranges from memblock instead of resource tree Wandun Chen
2026-10-21 9:05 ` Jinjie Ruan
2026-10-21 8:30 ` [PATCH v9 2/8] crash_core: fold duplicated memblock arch hooks into the weak default Wandun Chen
2026-10-21 8:30 ` [PATCH v9 3/8] crash_core: serialize crash header preparation against hotplug Wandun Chen
2026-10-21 9:10 ` Jinjie Ruan
2026-10-21 9:13 ` Jinjie Ruan
2026-10-21 9:48 ` Wandun
2026-10-22 2:00 ` Jinjie Ruan
2026-10-22 7:44 ` Wandun [this message]
2026-10-21 8:30 ` [PATCH v9 4/8] crash_core: replace for_each_mem_range() with for_each_mem_region() Wandun Chen
2026-10-21 8:30 ` [PATCH v9 5/8] memblock: introduce MEMBLOCK_NODUMP flag Wandun Chen
2026-10-21 8:30 ` [PATCH v9 6/8] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-10-21 8:30 ` [PATCH v9 7/8] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP Wandun Chen
2026-10-21 8:30 ` [PATCH v9 8/8] crash_core: skip MEMBLOCK_NODUMP regions when building vmcore ELF header Wandun Chen
2026-10-21 13:23 ` [PATCH v9 0/8] kdump: reduce vmcore size and capture time Rob Herring
2026-10-22 7:04 ` Wandun
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=098ff899-81b9-4ccc-a143-1e324446258f@gmail.com \
--to=chenwandun1@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=baoquan.he@linux.dev \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux.dev \
--cc=kernel@xen0n.name \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=loongarch@lists.linux.dev \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=pasha.tatashin@soleen.com \
--cc=pjw@kernel.org \
--cc=pratyush@kernel.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=ruirui.yang@linux.dev \
--cc=saravanak@kernel.org \
--cc=tglx@kernel.org \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox