From: Wandun Chen <chenwandun1@gmail.com>
To: catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org,
pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, robh@kernel.org,
saravanak@kernel.org, akpm@linux-foundation.org,
baoquan.he@linux.dev, rppt@kernel.org, pasha.tatashin@soleen.com,
pratyush@kernel.org, m.szyprowski@samsung.com
Cc: mark.rutland@arm.com, kernel@xen0n.name, alex@ghiti.fr,
hpa@zytor.com, 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
Subject: [PATCH v6 04/10] crash_core: serialize crash header preparation against hotplug
Date: Wed, 2 Sep 2026 15:31:10 +0800 [thread overview]
Message-ID: <20260902073116.802752-5-chenwandun1@gmail.com> (raw)
In-Reply-To: <20260902073116.802752-1-chenwandun1@gmail.com>
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 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]
---
arch/x86/kernel/crash.c | 2 +-
include/linux/crash_core.h | 2 ++
kernel/crash_core.c | 17 +++++++++++++++--
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index e681ec9cf1dc..284d78bc3fd0 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 77285ae3ce60..3adee1ae120c 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>
@@ -338,8 +339,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;
@@ -376,6 +377,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();
+
+ 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
--
2.43.0
WARNING: multiple messages have this Message-ID (diff)
From: Wandun Chen <chenwandun1@gmail.com>
To: catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org,
pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, robh@kernel.org,
saravanak@kernel.org, akpm@linux-foundation.org,
baoquan.he@linux.dev, rppt@kernel.org, pasha.tatashin@soleen.com,
pratyush@kernel.org, m.szyprowski@samsung.com
Cc: mark.rutland@arm.com, kernel@xen0n.name, alex@ghiti.fr,
hpa@zytor.com, 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
Subject: [PATCH v6 04/10] crash_core: serialize crash header preparation against hotplug
Date: Wed, 2 Sep 2026 15:31:10 +0800 [thread overview]
Message-ID: <20260902073116.802752-5-chenwandun1@gmail.com> (raw)
In-Reply-To: <20260902073116.802752-1-chenwandun1@gmail.com>
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 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]
---
arch/x86/kernel/crash.c | 2 +-
include/linux/crash_core.h | 2 ++
kernel/crash_core.c | 17 +++++++++++++++--
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index e681ec9cf1dc..284d78bc3fd0 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 77285ae3ce60..3adee1ae120c 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>
@@ -338,8 +339,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;
@@ -376,6 +377,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();
+
+ 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
--
2.43.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-09-02 7:32 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 7:31 [PATCH v6 00/10] kdump: reduce vmcore size and capture time Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 01/10] mm: memblock: add missing HugeTLB flag name Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:43 ` sashiko-bot
2026-09-02 7:31 ` [PATCH v6 02/10] riscv: build crash_mem ranges from memblock instead of resource tree Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 03/10] crash_core: fold duplicated memblock arch hooks into the weak default Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` Wandun Chen [this message]
2026-09-02 7:31 ` [PATCH v6 04/10] crash_core: serialize crash header preparation against hotplug Wandun Chen
2026-09-02 7:31 ` [PATCH v6 05/10] crash_core: replace for_each_mem_range() with for_each_mem_region() Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 06/10] memblock: introduce MEMBLOCK_NODUMP flag Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 07/10] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 7:31 ` [PATCH v6 08/10] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-03 7:32 ` Marek Szyprowski
2026-09-03 7:32 ` Marek Szyprowski
2026-09-02 7:31 ` [PATCH v6 09/10] of: reserved_mem: mark /memreserve/ entries as MEMBLOCK_NODUMP Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 9:02 ` sashiko-bot
2026-09-03 7:32 ` Marek Szyprowski
2026-09-03 7:32 ` Marek Szyprowski
2026-09-02 7:31 ` [PATCH v6 10/10] crash_core: skip MEMBLOCK_NODUMP regions when building vmcore ELF header Wandun Chen
2026-09-02 7:31 ` Wandun Chen
2026-09-02 8:53 ` [PATCH v6 00/10] kdump: reduce vmcore size and capture time Baoquan He
2026-09-02 8:53 ` Baoquan He
2026-09-03 7:05 ` Wandun
2026-09-03 7:05 ` Wandun
2026-09-03 7:31 ` Baoquan He
2026-09-03 7:31 ` Baoquan He
2026-09-03 7:43 ` Wandun
2026-09-03 7:43 ` Wandun
2026-09-03 9:38 ` Baoquan He
2026-09-03 9:38 ` Baoquan He
2026-09-04 11:08 ` Chen Wandun
2026-09-04 11:08 ` Chen 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=20260902073116.802752-5-chenwandun1@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=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 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.