* [PATCH v5 01/17] kexec: Fix CMA segment address translation with non-zero text_offset
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:22 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 02/17] kexec: Record allocated CMA pages to fix release size mismatch Jinjie Ruan
` (16 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
kimage_load_cma_segment() and kimage_map_segment() translate a CMA
segment to a kernel virtual address with page_address(cma), ignoring
segment->mem. But arm64's image_load() adds text_offset to segment->mem,
so the kernel payload is copied to the wrong offset while image->start
points past it, and kexec jumps into the middle of the kernel.
kimage_map_segment() has the same problem for any CMA segment whose mem
was moved.
Add kimage_cma_vaddr() to translate a boot physical address inside a CMA
segment to its virtual address, and use it in both places.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Pingfan Liu <piliu@redhat.com>
Cc: Justinien Bouron <jbouron@amazon.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: stable@vger.kernel.org
Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
kernel/kexec_core.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index dc770b9a6d05..7f7cb77f0caa 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -738,11 +738,23 @@ static struct page *kimage_alloc_page(struct kimage *image,
return page;
}
+/*
+ * Translate a boot physical address inside a CMA segment to a kernel
+ * virtual address. Architecture loaders may move segment->mem away from
+ * the CMA base (arm64 adds text_offset), so the offset must be preserved.
+ */
+static void *kimage_cma_vaddr(struct page *cma, unsigned long mem)
+{
+ unsigned long cma_base = page_to_boot_pfn(cma) << PAGE_SHIFT;
+
+ return page_address(cma) + (mem - cma_base);
+}
+
static int kimage_load_cma_segment(struct kimage *image, int idx)
{
struct kexec_segment *segment = &image->segment[idx];
struct page *cma = image->segment_cma[idx];
- char *ptr = page_address(cma);
+ char *ptr = kimage_cma_vaddr(cma, segment->mem);
size_t ubytes, mbytes;
int result = 0;
unsigned char __user *buf = NULL;
@@ -965,7 +977,7 @@ void *kimage_map_segment(struct kimage *image, int idx)
cma = image->segment_cma[idx];
if (cma)
- return page_address(cma);
+ return kimage_cma_vaddr(cma, image->segment[idx].mem);
addr = image->segment[idx].mem;
size = image->segment[idx].memsz;
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 01/17] kexec: Fix CMA segment address translation with non-zero text_offset
2026-09-18 10:04 ` [PATCH v5 01/17] kexec: Fix CMA segment address translation with non-zero text_offset Jinjie Ruan
@ 2026-09-18 10:22 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:22 UTC (permalink / raw)
To: loongarch, pratyush, kas, Jinjie Ruan, kees, rppt, rafael,
linux-mm, kernel, dakr, maddy, catalin.marinas, robh, chleroy,
ritesh.list, thuth, ruirui.yang, npiggin, mclapinski, graf,
eric.devolder, vishal.l.verma, leitao, ardb, x86, bgwin,
driver-core, me, mpe, chenhuacai, takahiro.akashi, james.morse,
chao.gao, liukexin, seanjc, palmer, pasha.tatashin, gshan,
hbathini, coxu, will, ruanjinjie, maqianga, piliu, guodongtai,
baoquan.he, sourabhjain, linux-fsdevel, linux-kernel, mark.rutl
Cc: kexec
> kimage_load_cma_segment() and kimage_map_segment() translate a CMA
> segment to a kernel virtual address with page_address(cma), ignoring
> segment->mem. But arm64's image_load() adds text_offset to segment->mem,
> so the kernel payload is copied to the wrong offset while image->start
> points past it, and kexec jumps into the middle of the kernel.
> kimage_map_segment() has the same problem for any CMA segment whose mem
> was moved.
>
> Add kimage_cma_vaddr() to translate a boot physical address inside a CMA
> segment to its virtual address, and use it in both places.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Pingfan Liu <piliu@redhat.com>
> Cc: Justinien Bouron <jbouron@amazon.com>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: stable@vger.kernel.org
> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=1
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 02/17] kexec: Record allocated CMA pages to fix release size mismatch
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
2026-09-18 10:04 ` [PATCH v5 01/17] kexec: Fix CMA segment address translation with non-zero text_offset Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:16 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 03/17] kexec: Extract kexec_free_segment_cma() from kimage_free_cma() Jinjie Ruan
` (15 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
The CMA pages allocated for a kexec segment are released using the
segment's memsz to calculate the number of pages. However, some
architecture loaders modify the segment's memsz after allocation
(e.g. arm64 subtracts text_offset), causing the release function to
free fewer pages than were originally allocated, leaking the remaining
CMA pages.
Add a per-segment `segment_cma_pages` array to store the number of
pages actually allocated from CMA. Populate it during
kexec_add_buffer() using the aligned memsz, and use it in
kimage_free_cma() to accurately release all allocated pages.
This avoids relying on the potentially modified segment->memsz and
prevents silent CMA memory leaks.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Brian Mak <makb@juniper.net>
Cc: Pingfan Liu <piliu@redhat.com>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Justinien Bouron <jbouron@amazon.com>
Cc: Li Chen <me@linux.beauty>
Cc: stable@vger.kernel.org
Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
include/linux/kexec.h | 1 +
kernel/kexec_core.c | 7 ++++---
kernel/kexec_file.c | 13 +++++++++----
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 0af8ae4fdd08..6b1df80524bf 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -349,6 +349,7 @@ struct kimage {
unsigned long nr_segments;
struct kexec_segment segment[KEXEC_SEGMENT_MAX];
struct page *segment_cma[KEXEC_SEGMENT_MAX];
+ unsigned long segment_cma_pages[KEXEC_SEGMENT_MAX];
struct list_head control_pages;
struct list_head dest_pages;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 7f7cb77f0caa..5493591a9e4b 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -560,14 +560,15 @@ static void kimage_free_cma(struct kimage *image)
for (i = 0; i < image->nr_segments; i++) {
struct page *cma = image->segment_cma[i];
- u32 nr_pages = image->segment[i].memsz >> PAGE_SHIFT;
+ unsigned long nr_pages = image->segment_cma_pages[i];
if (!cma)
continue;
- arch_kexec_pre_free_pages(page_address(cma), nr_pages);
- dma_release_from_contiguous(NULL, cma, nr_pages);
+ arch_kexec_pre_free_pages(page_address(cma), (unsigned int)nr_pages);
+ dma_release_from_contiguous(NULL, cma, (int)nr_pages);
image->segment_cma[i] = NULL;
+ image->segment_cma_pages[i] = 0;
}
}
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 59fb9d71e9d8..67d6df9824e6 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -670,7 +670,7 @@ static int kexec_walk_resources(struct kexec_buf *kbuf,
static int kexec_alloc_contig(struct kexec_buf *kbuf)
{
- size_t nr_pages = kbuf->memsz >> PAGE_SHIFT;
+ size_t nr_pages = PFN_DOWN(kbuf->memsz);
unsigned long mem;
struct page *p;
@@ -756,14 +756,16 @@ int kexec_locate_mem_hole(struct kexec_buf *kbuf)
*/
int kexec_add_buffer(struct kexec_buf *kbuf)
{
+ unsigned long nr_segments = kbuf->image->nr_segments;
struct kexec_segment *ksegment;
+ size_t nr_cma_pages = 0;
int ret;
/* Currently adding segment this way is allowed only in file mode */
if (!kbuf->image->file_mode)
return -EINVAL;
- if (kbuf->image->nr_segments >= KEXEC_SEGMENT_MAX)
+ if (nr_segments >= KEXEC_SEGMENT_MAX)
return -EINVAL;
/*
@@ -789,12 +791,15 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
return ret;
/* Found a suitable memory range */
- ksegment = &kbuf->image->segment[kbuf->image->nr_segments];
+ ksegment = &kbuf->image->segment[nr_segments];
ksegment->kbuf = kbuf->buffer;
ksegment->bufsz = kbuf->bufsz;
ksegment->mem = kbuf->mem;
ksegment->memsz = kbuf->memsz;
- kbuf->image->segment_cma[kbuf->image->nr_segments] = kbuf->cma;
+ kbuf->image->segment_cma[nr_segments] = kbuf->cma;
+ if (kbuf->cma)
+ nr_cma_pages = PFN_DOWN(kbuf->memsz);
+ kbuf->image->segment_cma_pages[nr_segments] = nr_cma_pages;
kbuf->image->nr_segments++;
return 0;
}
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 02/17] kexec: Record allocated CMA pages to fix release size mismatch
2026-09-18 10:04 ` [PATCH v5 02/17] kexec: Record allocated CMA pages to fix release size mismatch Jinjie Ruan
@ 2026-09-18 10:16 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:16 UTC (permalink / raw)
To: gregkh, dakr, maddy, mingo, bp, ruanjinjie, ardb, robh,
vishal.l.verma, me, kas, bgwin, linux-kernel, chleroy,
baoquan.he, rppt, will, rafael, lizhengyu3, hpa, yeoreum.yun,
tangyouling, graf, eric.devolder, sshegde, kernel, loongarch,
gshan, thuth, linux-mm, sourabhjain, hbathini, ritesh.list,
mark.rutland, adityag, guodongtai, catalin.marinas, maqianga,
seanjc, kees, dave.hansen, ruirui.yang, x86, palmer, piliu,
pratyush, james.morse, tglx
Cc: kexec
> The CMA pages allocated for a kexec segment are released using the
> segment's memsz to calculate the number of pages. However, some
> architecture loaders modify the segment's memsz after allocation
> (e.g. arm64 subtracts text_offset), causing the release function to
> free fewer pages than were originally allocated, leaking the remaining
> CMA pages.
>
> Add a per-segment `segment_cma_pages` array to store the number of
> pages actually allocated from CMA. Populate it during
> kexec_add_buffer() using the aligned memsz, and use it in
> kimage_free_cma() to accurately release all allocated pages.
>
> This avoids relying on the potentially modified segment->memsz and
> prevents silent CMA memory leaks.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Brian Mak <makb@juniper.net>
> Cc: Pingfan Liu <piliu@redhat.com>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: Justinien Bouron <jbouron@amazon.com>
> Cc: Li Chen <me@linux.beauty>
> Cc: stable@vger.kernel.org
> Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=2
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 03/17] kexec: Extract kexec_free_segment_cma() from kimage_free_cma()
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
2026-09-18 10:04 ` [PATCH v5 01/17] kexec: Fix CMA segment address translation with non-zero text_offset Jinjie Ruan
2026-09-18 10:04 ` [PATCH v5 02/17] kexec: Record allocated CMA pages to fix release size mismatch Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:18 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 04/17] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
` (14 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
kimage_free_cma() relies on image->nr_segments to iterate over segments.
When an architecture loader (e.g., arm64) truncates nr_segments on a
mid-way failure, CMA pages allocated beyond the new boundary become
unreachable, causing silent memory leaks.
Extract the per-segment freeing logic into the exported helper
kexec_free_segment_cma(), so that architecture loaders can release
individual segments before nr_segments is truncated. Refactor
kimage_free_cma() to loop over the new helper, preserving existing
behavior.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
include/linux/kexec.h | 2 ++
kernel/kexec_core.c | 27 +++++++++++++++------------
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 6b1df80524bf..72258d813301 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -533,6 +533,7 @@ extern bool kexec_file_dbg_print;
extern void *kimage_map_segment(struct kimage *image, int idx);
extern void kimage_unmap_segment(void *buffer);
+void kexec_free_segment_cma(struct kimage *image, unsigned long idx);
#else /* !CONFIG_KEXEC_CORE */
struct pt_regs;
struct task_struct;
@@ -544,6 +545,7 @@ static inline int kexec_crash_loaded(void) { return 0; }
static inline void *kimage_map_segment(struct kimage *image, int idx)
{ return NULL; }
static inline void kimage_unmap_segment(void *buffer) { }
+static inline void kexec_free_segment_cma(struct kimage *image, unsigned long idx) { }
#define kexec_in_progress false
#endif /* CONFIG_KEXEC_CORE */
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 5493591a9e4b..31c8228318a7 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -554,23 +554,26 @@ static void kimage_free_entry(kimage_entry_t entry)
kimage_free_pages(page);
}
-static void kimage_free_cma(struct kimage *image)
+void kexec_free_segment_cma(struct kimage *image, unsigned long idx)
{
- unsigned long i;
+ unsigned long nr_pages = image->segment_cma_pages[idx];
+ struct page *cma = image->segment_cma[idx];
- for (i = 0; i < image->nr_segments; i++) {
- struct page *cma = image->segment_cma[i];
- unsigned long nr_pages = image->segment_cma_pages[i];
+ if (!cma)
+ return;
- if (!cma)
- continue;
+ arch_kexec_pre_free_pages(page_address(cma), (unsigned int)nr_pages);
+ dma_release_from_contiguous(NULL, cma, (int)nr_pages);
+ image->segment_cma[idx] = NULL;
+ image->segment_cma_pages[idx] = 0;
+}
- arch_kexec_pre_free_pages(page_address(cma), (unsigned int)nr_pages);
- dma_release_from_contiguous(NULL, cma, (int)nr_pages);
- image->segment_cma[i] = NULL;
- image->segment_cma_pages[i] = 0;
- }
+static void kimage_free_cma(struct kimage *image)
+{
+ unsigned long i;
+ for (i = 0; i < image->nr_segments; i++)
+ kexec_free_segment_cma(image, i);
}
void kimage_free(struct kimage *image)
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 03/17] kexec: Extract kexec_free_segment_cma() from kimage_free_cma()
2026-09-18 10:04 ` [PATCH v5 03/17] kexec: Extract kexec_free_segment_cma() from kimage_free_cma() Jinjie Ruan
@ 2026-09-18 10:18 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:18 UTC (permalink / raw)
To: x86, me, vishal.l.verma, npiggin, sourabhjain, lizhengyu3, dakr,
blum, linux-mm, dave.hansen, eric.devolder, adityag, akpm, will,
takahiro.akashi, bgwin, catalin.marinas, coxu, zhangtianyang,
driver-core, kernel, kees, hpa, kas, seanjc, linux-kernel, mingo,
ritesh.list, sshegde, ruirui.yang, jbouron, leitao, tglx,
chenhuacai, hbathini, james.morse, mclapinski, palmer,
ruanjinjie, linux-arm-kernel, robh, linux-fsdevel, maqianga,
gshan, chleroy, liuk
Cc: kexec
> kimage_free_cma() relies on image->nr_segments to iterate over segments.
> When an architecture loader (e.g., arm64) truncates nr_segments on a
> mid-way failure, CMA pages allocated beyond the new boundary become
> unreachable, causing silent memory leaks.
>
> Extract the per-segment freeing logic into the exported helper
> kexec_free_segment_cma(), so that architecture loaders can release
> individual segments before nr_segments is truncated. Refactor
> kimage_free_cma() to loop over the new helper, preserving existing
> behavior.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=3
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 04/17] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (2 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 03/17] kexec: Extract kexec_free_segment_cma() from kimage_free_cma() Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:15 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 05/17] arm64: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
` (13 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
During kexec image placement retry loops, any midway failure causes
the loader to truncate `image->nr_segments` back to its initial state
to purge the failed segments.
However, this truncation introduces a memory leak. The CMA pages
allocated via kexec_add_buffer() during the failed attempt are tracked
in the `image->segment_cma` array. Because the subsequent cleanup paths
only iterate up to the truncated `nr_segments` boundary, these allocated
CMA pages outside the new boundary are permanently leaked.
Fix this by explicitly releasing the associated CMA buffers in
the failure paths before `image->nr_segments` is reduced.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Breno Leitao <leitao@debian.org>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 07d24902977e4 ("kexec: enable CMA based contiguous allocation")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/kexec_image.c | 1 +
arch/arm64/kernel/machine_kexec_file.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index b70f4df15a1a..ffcb7f9075e6 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -107,6 +107,7 @@ static void *image_load(struct kimage *image,
* We couldn't find space for the other segments; erase the
* kernel segment and try the next available hole.
*/
+ kexec_free_segment_cma(image, kernel_segment_number);
image->nr_segments -= 1;
kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz;
kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 854d872dfd0f..e48f29167b38 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -179,7 +179,10 @@ int load_other_segments(struct kimage *image,
return 0;
out_err:
- image->nr_segments = orig_segments;
+ while (image->nr_segments > orig_segments) {
+ kexec_free_segment_cma(image, image->nr_segments - 1);
+ image->nr_segments--;
+ }
kvfree(dtb);
return ret;
}
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 04/17] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops
2026-09-18 10:04 ` [PATCH v5 04/17] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
@ 2026-09-18 10:15 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:15 UTC (permalink / raw)
To: ruanjinjie, graf, gshan, pasha.tatashin, catalin.marinas, tglx,
pratyush, ruirui.yang, linux-arm-kernel, bgwin, palmer, mpe,
hbathini, hpa, sourabhjain, robh, adityag, zhangtianyang,
linux-fsdevel, akpm, guodongtai, linux-kernel, linux-mm, me, x86,
ritesh.list, eric.devolder, Jinjie Ruan, blum, coxu, rafael,
jbouron, rppt, tangyouling, maqianga, sshegde, kernel, dakr,
thuth, seanjc, npiggin, vishal.l.verma, chao.gao, liukexin,
piliu, linuxppc-dev, takahiro.akashi, kees, baoquan.he,
james.morse, yeoreum.yun, dave.hansen, driver-core, ardb, gregkh,
leitao, chenhuacai, kas, loongarch, mclapinski, bp, lizhengyu3,
mingo, will, mark.rutland, maddy, chleroy
Cc: kexec
> During kexec image placement retry loops, any midway failure causes
> the loader to truncate `image->nr_segments` back to its initial state
> to purge the failed segments.
>
> However, this truncation introduces a memory leak. The CMA pages
> allocated via kexec_add_buffer() during the failed attempt are tracked
> in the `image->segment_cma` array. Because the subsequent cleanup paths
> only iterate up to the truncated `nr_segments` boundary, these allocated
> CMA pages outside the new boundary are permanently leaked.
>
> Fix this by explicitly releasing the associated CMA buffers in
> the failure paths before `image->nr_segments` is reduced.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Breno Leitao <leitao@debian.org>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Yeoreum Yun <yeoreum.yun@arm.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: stable@vger.kernel.org
> Fixes: 07d24902977e4 ("kexec: enable CMA based contiguous allocation")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=4
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 05/17] arm64: kexec_file: Fix elf_headers memory leak in retry loop
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (3 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 04/17] arm64: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:16 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 06/17] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
` (12 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
If load_other_segments() fails after image->elf_headers is assigned,
the memory lifecycle is safely managed by the global kimage object
and will be freed in arch_kimage_file_post_load_cleanup().
However, during a retry loop in image_load(), a subsequent iteration
will allocate a new buffer and overwrite image->elf_headers. This
permanently leaks the stale memory from the previous iteration before
the global cleanup can track it.
Fix this by explicitly freeing the stale `image->elf_headers` buffer
before assigning the newly allocated headers.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Thomas Huth <thuth@redhat.com>
Cc: Breno Leitao <leitao@debian.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 108aa503657e ("arm64: kexec_file: try more regions if loading segments fails")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/machine_kexec_file.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index e48f29167b38..2f750e5f4fcc 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -112,6 +112,10 @@ int load_other_segments(struct kimage *image,
vfree(headers);
goto out_err;
}
+
+ if (unlikely(image->elf_headers))
+ vfree(image->elf_headers);
+
image->elf_headers = headers;
image->elf_load_addr = kbuf.mem;
image->elf_headers_sz = headers_sz;
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 05/17] arm64: kexec_file: Fix elf_headers memory leak in retry loop
2026-09-18 10:04 ` [PATCH v5 05/17] arm64: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
@ 2026-09-18 10:16 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:16 UTC (permalink / raw)
To: maqianga, dave.hansen, dakr, pratyush, vishal.l.verma,
mark.rutland, hbathini, linuxppc-dev, kernel, mpe, sourabhjain,
eric.devolder, linux-fsdevel, gshan, x86, hpa, lizhengyu3, kees,
adityag, ruirui.yang, yeoreum.yun, chao.gao, ardb, piliu, graf,
james.morse, zhangtianyang, tglx, will, rppt, rafael,
pasha.tatashin, thuth, akpm, blum, palmer, coxu,
linux-arm-kernel, chenhuacai, robh, seanjc, linux-kernel, bp,
takahiro.akashi, bgwin, maddy
Cc: kexec
> If load_other_segments() fails after image->elf_headers is assigned,
> the memory lifecycle is safely managed by the global kimage object
> and will be freed in arch_kimage_file_post_load_cleanup().
>
> However, during a retry loop in image_load(), a subsequent iteration
> will allocate a new buffer and overwrite image->elf_headers. This
> permanently leaks the stale memory from the previous iteration before
> the global cleanup can track it.
>
> Fix this by explicitly freeing the stale `image->elf_headers` buffer
> before assigning the newly allocated headers.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Thomas Huth <thuth@redhat.com>
> Cc: Breno Leitao <leitao@debian.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Yeoreum Yun <yeoreum.yun@arm.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: stable@vger.kernel.org
> Fixes: 108aa503657e ("arm64: kexec_file: try more regions if loading segments fails")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=5
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 06/17] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (4 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 05/17] arm64: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:16 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 07/17] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
` (11 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
During kexec image placement retry loops, any midway failure causes
the loader to truncate `image->nr_segments` back to its initial state
to purge the failed segments.
However, this truncation introduces a memory leak. The CMA pages
allocated via kexec_add_buffer() during the failed attempt are tracked
in the `image->segment_cma` array. Because the subsequent cleanup paths
only iterate up to the truncated `nr_segments` boundary, these allocated
CMA pages outside the new boundary are permanently leaked.
Fix this by explicitly releasing the associated CMA buffers in
the failure paths before `image->nr_segments` is reduced.
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Kees Cook <kees@kernel.org>
Cc: stable@vger.kernel.org
Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
Fixes: 55d990f0084c ("LoongArch: Add EFI binary support for kexec_file")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/loongarch/kernel/kexec_efi.c | 1 +
arch/loongarch/kernel/machine_kexec_file.c | 6 +++++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/loongarch/kernel/kexec_efi.c b/arch/loongarch/kernel/kexec_efi.c
index 5ee78ebb1546..15fd797ff3de 100644
--- a/arch/loongarch/kernel/kexec_efi.c
+++ b/arch/loongarch/kernel/kexec_efi.c
@@ -86,6 +86,7 @@ static void *efi_kexec_load(struct kimage *image,
* We couldn't find space for the other segments; erase the
* kernel segment and try the next available hole.
*/
+ kexec_free_segment_cma(image, kernel_segment_number);
image->nr_segments -= 1;
kbuf.buf_min = kernel_segment->mem + kernel_segment->memsz;
kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 5412aa9f3568..62a5be102065 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -217,7 +217,11 @@ int load_other_segments(struct kimage *image,
return 0;
out_err:
- image->nr_segments = orig_segments;
+ while (image->nr_segments > orig_segments) {
+ kexec_free_segment_cma(image, image->nr_segments - 1);
+ image->nr_segments--;
+ }
+
kfree(modified_cmdline);
return ret;
}
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 06/17] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops
2026-09-18 10:04 ` [PATCH v5 06/17] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
@ 2026-09-18 10:16 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:16 UTC (permalink / raw)
To: maqianga, mpe, akpm, catalin.marinas, dave.hansen, graf,
vishal.l.verma, me, mclapinski, hpa, sshegde, yeoreum.yun,
pratyush, eric.devolder, gshan, bgwin, guodongtai, ruirui.yang,
ruanjinjie, kernel, piliu, driver-core, linux-arm-kernel,
mark.rutland, lizhengyu3, james.morse, chenhuacai, sourabhjain,
adityag, linux-kernel, linux-fsdevel, robh, npiggin, dakr,
ritesh.list, takahiro.akashi, thuth, linux-mm, liukexin, palmer,
rppt, x86, coxu, loongarch, bp, ardb, zhangtianyang, chleroy,
chao.gao, linuxppc-dev, Jinjie Ruan, maddy, blum, seanjc, gregkh,
baoquan.he, pasha.tatashin, rafael, tglx, kas, hbathini,
tangyouling, jbouron, kees, will, leitao, mingo
Cc: kexec
> During kexec image placement retry loops, any midway failure causes
> the loader to truncate `image->nr_segments` back to its initial state
> to purge the failed segments.
>
> However, this truncation introduces a memory leak. The CMA pages
> allocated via kexec_add_buffer() during the failed attempt are tracked
> in the `image->segment_cma` array. Because the subsequent cleanup paths
> only iterate up to the truncated `nr_segments` boundary, these allocated
> CMA pages outside the new boundary are permanently leaked.
>
> Fix this by explicitly releasing the associated CMA buffers in
> the failure paths before `image->nr_segments` is reduced.
>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Cc: Youling Tang <tangyouling@kylinos.cn>
> Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: Kees Cook <kees@kernel.org>
> Cc: stable@vger.kernel.org
> Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
> Fixes: 55d990f0084c ("LoongArch: Add EFI binary support for kexec_file")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=6
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 07/17] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (5 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 06/17] LoongArch: kexec_file: Fix CMA page leaks in segment placement retry loops Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:21 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 08/17] LoongArch: kexec_file: Fix a modified_cmdline leak Jinjie Ruan
` (10 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
If load_other_segments() fails after image->elf_headers is assigned,
the memory lifecycle is safely managed by the global kimage object
and will be freed in arch_kimage_file_post_load_cleanup().
However, during a retry loop in efi_kexec_load(), a subsequent iteration
will allocate a new buffer and overwrite image->elf_headers. This
permanently leaks the stale memory from the previous iteration before
the global cleanup can track it.
Fix this by explicitly freeing the stale `image->elf_headers` buffer
before assigning the newly allocated headers.
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Kees Cook <kees@kernel.org>
Cc: stable@vger.kernel.org
Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
Fixes: 55d990f0084c ("LoongArch: Add EFI binary support for kexec_file")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/loongarch/kernel/machine_kexec_file.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 62a5be102065..3beb6977ecc6 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -166,6 +166,10 @@ int load_other_segments(struct kimage *image,
vfree(headers);
goto out_err;
}
+
+ if (unlikely(image->elf_headers))
+ vfree(image->elf_headers);
+
image->elf_headers = headers;
image->elf_load_addr = kbuf.mem;
image->elf_headers_sz = headers_sz;
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 07/17] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop
2026-09-18 10:04 ` [PATCH v5 07/17] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
@ 2026-09-18 10:21 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:21 UTC (permalink / raw)
To: leitao, seanjc, kees, thuth, tglx, loongarch, will, hbathini,
rppt, akpm, chao.gao, hpa, guodongtai, takahiro.akashi, maddy,
pratyush, Jinjie Ruan, zhangtianyang, lizhengyu3, blum, x86,
eric.devolder, catalin.marinas, ruirui.yang, me, adityag,
ruanjinjie, vishal.l.verma, mark.rutland, sourabhjain,
linux-kernel, rafael, chenhuacai, pasha.tatashin, palmer,
ritesh.list, kernel, robh, dakr, james.morse, mingo, tangyouling,
mclapinski, linuxppc-dev, linux-fsdevel, jbouron, sshegde, graf,
bgwin, bp, linux-mm, chleroy, piliu, maqianga, gshan,
yeoreum.yun, coxu, mpe, dave.hansen, npiggin, baoquan.he, kas
Cc: kexec
> If load_other_segments() fails after image->elf_headers is assigned,
> the memory lifecycle is safely managed by the global kimage object
> and will be freed in arch_kimage_file_post_load_cleanup().
>
> However, during a retry loop in efi_kexec_load(), a subsequent iteration
> will allocate a new buffer and overwrite image->elf_headers. This
> permanently leaks the stale memory from the previous iteration before
> the global cleanup can track it.
>
> Fix this by explicitly freeing the stale `image->elf_headers` buffer
> before assigning the newly allocated headers.
>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Cc: Youling Tang <tangyouling@kylinos.cn>
> Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: Kees Cook <kees@kernel.org>
> Cc: stable@vger.kernel.org
> Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
> Fixes: 55d990f0084c ("LoongArch: Add EFI binary support for kexec_file")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=7
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 08/17] LoongArch: kexec_file: Fix a modified_cmdline leak
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (6 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 07/17] LoongArch: kexec_file: Fix elf_headers memory leak in retry loop Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:18 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 09/17] x86/crash: Fix massive out-of-bounds write on 32-bit Highmem Jinjie Ruan
` (9 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
load_other_segments() allocates modified_cmdline and stores it in
image->arch.cmdline_ptr. machine_kexec_prepare() then copies it to
KEXEC_CMDLINE_ADDR and overwrites the pointer, so the heap buffer is
leaked on every successful kexec_file_load().
Free the buffer after the copy.
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Kexin Liu <liukexin@kylinos.cn>
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: Qiang Ma <maqianga@uniontech.com>
Cc: Tianyang Zhang <zhangtianyang@loongson.cn>
Cc: George Guo <guodongtai@kylinos.cn>
Cc: stable@vger.kernel.org
Fixes: d162feec6b6e ("LoongArch: Add preparatory infrastructure for kexec_file")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/loongarch/kernel/machine_kexec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/loongarch/kernel/machine_kexec.c b/arch/loongarch/kernel/machine_kexec.c
index 1883cae93bc3..19ccc91b6f2a 100644
--- a/arch/loongarch/kernel/machine_kexec.c
+++ b/arch/loongarch/kernel/machine_kexec.c
@@ -14,6 +14,7 @@
#include <linux/mm.h>
#include <linux/of_fdt.h>
#include <linux/reboot.h>
+#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/sched/task_stack.h>
@@ -56,6 +57,7 @@ int machine_kexec_prepare(struct kimage *kimage)
*/
memcpy((void *)KEXEC_CMDLINE_ADDR, (void *)kimage->arch.cmdline_ptr,
strlen((char *)kimage->arch.cmdline_ptr) + 1);
+ kfree((void *)kimage->arch.cmdline_ptr);
kimage->arch.cmdline_ptr = (unsigned long)KEXEC_CMDLINE_ADDR;
} else {
/* Find the command line */
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 08/17] LoongArch: kexec_file: Fix a modified_cmdline leak
2026-09-18 10:04 ` [PATCH v5 08/17] LoongArch: kexec_file: Fix a modified_cmdline leak Jinjie Ruan
@ 2026-09-18 10:18 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:18 UTC (permalink / raw)
To: rafael, mingo, leitao, graf, ritesh.list, coxu, sshegde,
catalin.marinas, bp, blum, chao.gao, linuxppc-dev, chenhuacai,
jbouron, eric.devolder, palmer, akpm, linux-kernel, hbathini,
rppt, james.morse, will, maddy, chleroy, dave.hansen,
sourabhjain, mpe, baoquan.he, linux-mm, linux-fsdevel, gshan,
gregkh, lizhengyu3, adityag, tglx, guodongtai, Jinjie Ruan, me,
hpa, x86, piliu, ardb, takahiro.akashi, npiggin, maqianga,
mclapinski, yeoreum.yun, kernel, vishal.l.verma, bgwin,
driver-core, seanjc, kas, tangyouling, pasha.tatashin,
zhangtianyang, ruanjinjie, ruirui.yang, kees, thuth,
linux-arm-kernel, liukexin, dakr, pratyush, robh, mark.rutland,
loongarch
Cc: kexec
> load_other_segments() allocates modified_cmdline and stores it in
> image->arch.cmdline_ptr. machine_kexec_prepare() then copies it to
> KEXEC_CMDLINE_ADDR and overwrites the pointer, so the heap buffer is
> leaked on every successful kexec_file_load().
>
> Free the buffer after the copy.
>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> Cc: WANG Xuerui <kernel@xen0n.name>
> Cc: Kexin Liu <liukexin@kylinos.cn>
> Cc: Youling Tang <tangyouling@kylinos.cn>
> Cc: Qiang Ma <maqianga@uniontech.com>
> Cc: Tianyang Zhang <zhangtianyang@loongson.cn>
> Cc: George Guo <guodongtai@kylinos.cn>
> Cc: stable@vger.kernel.org
> Fixes: d162feec6b6e ("LoongArch: Add preparatory infrastructure for kexec_file")
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=8
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 09/17] x86/crash: Fix massive out-of-bounds write on 32-bit Highmem
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (7 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 08/17] LoongArch: kexec_file: Fix a modified_cmdline leak Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:16 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 10/17] crash: Extract crash_get_memory_ranges() helper Jinjie Ruan
` (8 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
On 32-bit x86 systems with HIGHMEM, kmap_local_page() only maps a single
4KB page. However, the elfcorehdr segment can span several pages (up to
hundreds of kilobytes).
The original code blindly copies 'elfsz' bytes at once via
memcpy_flushcache(), overwriting adjacent fixmap entries or critical
virtual addresses.
Fix this by copying the new elfcorehdr page by page.
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Chao Gao <chao.gao@intel.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Eric DeVolder <eric.devolder@oracle.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: stable@vger.kernel.org
Fixes: ea53ad9cf73b ("x86/crash: add x86 crash hotplug support")
Link: https://sashiko.dev/#/patchset/20260907125404.922123-1-ruanjinjie%40huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/x86/kernel/crash.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index e681ec9cf1dc..3c9f4fbbe7ff 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -447,9 +447,10 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
*/
void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
{
- void *elfbuf = NULL, *old_elfcorehdr;
unsigned long mem, memsz;
unsigned long elfsz = 0;
+ void *elfbuf = NULL;
+ unsigned long done;
/*
* As crash_prepare_elf64_headers() has already described all
@@ -484,21 +485,20 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
/*
* Copy new elfcorehdr over the old elfcorehdr at destination.
- */
- old_elfcorehdr = kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT));
- if (!old_elfcorehdr) {
- pr_err("mapping elfcorehdr segment failed\n");
- goto out;
- }
-
- /*
- * Temporarily invalidate the crash image while the
- * elfcorehdr is updated.
+ * The segment is physically contiguous but can span several pages.
+ * On 32-bit Highmem architectures, kmap_local_page() maps only a
+ * single page at a time, so copy page by page.
*/
xchg(&kexec_crash_image, NULL);
- memcpy_flushcache(old_elfcorehdr, elfbuf, elfsz);
+ for (done = 0; done < elfsz; ) {
+ size_t chunk = min_t(size_t, PAGE_SIZE, elfsz - done);
+ void *dst = kmap_local_page(pfn_to_page((mem + done) >> PAGE_SHIFT));
+
+ memcpy_flushcache(dst, elfbuf + done, chunk);
+ kunmap_local(dst);
+ done += chunk;
+ }
xchg(&kexec_crash_image, image);
- kunmap_local(old_elfcorehdr);
pr_debug("updated elfcorehdr\n");
out:
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 09/17] x86/crash: Fix massive out-of-bounds write on 32-bit Highmem
2026-09-18 10:04 ` [PATCH v5 09/17] x86/crash: Fix massive out-of-bounds write on 32-bit Highmem Jinjie Ruan
@ 2026-09-18 10:16 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:16 UTC (permalink / raw)
To: ruirui.yang, rppt, bp, vishal.l.verma, linux-arm-kernel,
yeoreum.yun, chao.gao, kernel, tglx, takahiro.akashi,
ritesh.list, hpa, sshegde, kees, tangyouling, will, piliu, me,
linux-fsdevel, linux-mm, maqianga, gregkh, pasha.tatashin,
npiggin, Jinjie Ruan, thuth, maddy, blum, chenhuacai, mpe,
sourabhjain, zhangtianyang, robh, graf, seanjc, hbathini,
guodongtai, rafael, adityag, kas, gshan, coxu, jbouron, liukexin,
driver-core, mclapinski, eric.devolder, linuxppc-dev, dakr,
dave.hansen, mingo, ruanjinjie, akpm, ardb, bgwin, linux-kernel,
james.morse, lizhengyu3, baoquan.he, loongarch, x86, palmer,
pratyush, catalin.marinas, leitao, mark.rutland, chleroy
Cc: kexec
> On 32-bit x86 systems with HIGHMEM, kmap_local_page() only maps a single
> 4KB page. However, the elfcorehdr segment can span several pages (up to
> hundreds of kilobytes).
>
> The original code blindly copies 'elfsz' bytes at once via
> memcpy_flushcache(), overwriting adjacent fixmap entries or critical
> virtual addresses.
>
> Fix this by copying the new elfcorehdr page by page.
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
> Cc: Vishal Verma <vishal.l.verma@intel.com>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Chao Gao <chao.gao@intel.com>
> Cc: Sean Christopherson <seanjc@google.com>
> Cc: Eric DeVolder <eric.devolder@oracle.com>
> Cc: Hari Bathini <hbathini@linux.ibm.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Cc: stable@vger.kernel.org
> Fixes: ea53ad9cf73b ("x86/crash: add x86 crash hotplug support")
> Link: https://sashiko.dev/#/patchset/20260907125404.922123-1-ruanjinjie%40huawei.com
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=9
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 10/17] crash: Extract crash_get_memory_ranges() helper
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (8 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 09/17] x86/crash: Fix massive out-of-bounds write on 32-bit Highmem Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:11 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 11/17] crash: Normalize the kexec_load elfcorehdr at load time Jinjie Ruan
` (7 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
Factor out the crash memory range collection logic from
crash_prepare_headers() into a separate function. This allows
the memory hotplug path to obtain and modify the range list
(e.g. remove offlined memory) before generating the elfcorehdr.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Dave Young <ruirui.yang@linux.dev>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
include/linux/crash_core.h | 1 +
kernel/crash_core.c | 22 +++++++++++++++++++---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index bc087124cd78..b1c816e98143 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -62,6 +62,7 @@ extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_ma
extern 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);
+int crash_get_memory_ranges(struct crash_mem **mem_ranges);
struct kimage;
struct kexec_segment;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 2b36aa9fade0..406b68d2adfd 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -317,8 +317,7 @@ 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_get_memory_ranges(struct crash_mem **mem_ranges)
{
unsigned int max_nr_ranges;
struct crash_mem *cmem;
@@ -344,13 +343,30 @@ int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
if (ret)
goto out;
+ *mem_ranges = cmem;
+ return 0;
+
+out:
+ kvfree(cmem);
+ return ret;
+}
+
+int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
+ unsigned long *nr_mem_ranges)
+{
+ struct crash_mem *cmem = NULL;
+ int ret;
+
+ ret = crash_get_memory_ranges(&cmem);
+ if (ret)
+ return ret;
+
/* Return the computed number of memory ranges, for hotplug usage */
if (nr_mem_ranges)
*nr_mem_ranges = cmem->nr_ranges;
ret = crash_prepare_elf64_headers(cmem, need_kernel_map, addr, sz);
-out:
kvfree(cmem);
return ret;
}
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 10/17] crash: Extract crash_get_memory_ranges() helper
2026-09-18 10:04 ` [PATCH v5 10/17] crash: Extract crash_get_memory_ranges() helper Jinjie Ruan
@ 2026-09-18 10:11 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:11 UTC (permalink / raw)
To: maddy, tglx, loongarch, hbathini, linux-kernel, catalin.marinas,
guodongtai, jbouron, thuth, mark.rutland, Jinjie Ruan, gshan,
sourabhjain, chao.gao, piliu, eric.devolder, baoquan.he,
pratyush, ruirui.yang, bgwin, chenhuacai, linux-arm-kernel,
maqianga, bp, tangyouling, mingo, driver-core, blum,
takahiro.akashi, coxu, linux-mm, palmer, akpm, ruanjinjie,
vishal.l.verma, npiggin, dave.hansen, liukexin, hpa, chleroy,
sshegde, linuxppc-dev, robh, lizhengyu3, leitao, yeoreum.yun,
kees, linux-fsdevel, mclapinski, james.morse, pasha.tatashin,
dakr, will, zhangtianyang, me
Cc: kexec
> Factor out the crash memory range collection logic from
> crash_prepare_headers() into a separate function. This allows
> the memory hotplug path to obtain and modify the range list
> (e.g. remove offlined memory) before generating the elfcorehdr.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Dave Young <ruirui.yang@linux.dev>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=10
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 11/17] crash: Normalize the kexec_load elfcorehdr at load time
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (9 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 10/17] crash: Extract crash_get_memory_ranges() helper Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:27 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 12/17] crash: Fix TOCTOU race in crash memory range collection Jinjie Ruan
` (6 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
For kexec_load() the kernel does not build the elfcorehdr, so it is only
rewritten by the first crash hotplug event. CPU hotplug events do not
change the elfcorehdr, but they may run without device_hotplug_lock
(e.g. CPU offlining during suspend), so they cannot perform that rewrite
without racing with memory hotplug.
Normalize the elfcorehdr once when the crash image is installed, while
device_hotplug_lock can still be taken safely, and let the hotplug paths
skip CPU events entirely.
The elfcorehdr segment is located by scanning the segments for the ELF
magic. Factor that scan out into crash_find_elfcorehdr() and reuse it
from crash_handle_hotplug_event(). Architectures that do not need the
rewrite (e.g. powerpc) treat KEXEC_CRASH_HP_NONE as a no-op.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/kexec/crash.c | 1 +
arch/x86/kernel/crash.c | 5 ++--
include/linux/crash_core.h | 1 +
kernel/crash_core.c | 58 +++++++++++++++++++++++++++-----------
kernel/kexec.c | 4 +++
5 files changed, 50 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index 775895f31037..8ede33740fc0 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -638,6 +638,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
struct memory_notify *mn;
switch (image->hp_action) {
+ case KEXEC_CRASH_HP_NONE:
case KEXEC_CRASH_HP_REMOVE_CPU:
return;
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 3c9f4fbbe7ff..f34fa8dba028 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -457,9 +457,8 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
* possible CPUs, there is no need to update the elfcorehdr
* for additional CPU changes.
*/
- if ((image->file_mode || image->elfcorehdr_updated) &&
- ((image->hp_action == KEXEC_CRASH_HP_ADD_CPU) ||
- (image->hp_action == KEXEC_CRASH_HP_REMOVE_CPU)))
+ if (image->hp_action == KEXEC_CRASH_HP_ADD_CPU ||
+ image->hp_action == KEXEC_CRASH_HP_REMOVE_CPU)
return;
/*
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index b1c816e98143..a740757dff35 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -39,6 +39,7 @@ static inline void arch_crash_handle_hotplug_event(struct kimage *image, void *a
#endif
int crash_check_hotplug_support(void);
+void crash_hotplug_prepare_elfcorehdr(struct kimage *image);
#ifndef arch_crash_hotplug_support
static inline int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_flags)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 406b68d2adfd..47a4579eb97e 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -647,6 +647,28 @@ int crash_check_hotplug_support(void)
return rc;
}
+static void crash_find_elfcorehdr(struct kimage *image)
+{
+ unsigned char *ptr;
+ unsigned long mem;
+ unsigned int n;
+
+ if (image->elfcorehdr_index >= 0)
+ return;
+
+ for (n = 0; n < image->nr_segments; n++) {
+ mem = image->segment[n].mem;
+ ptr = kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT));
+ if (!ptr)
+ continue;
+
+ /* The segment containing elfcorehdr */
+ if (memcmp(ptr, ELFMAG, SELFMAG) == 0)
+ image->elfcorehdr_index = (int)n;
+ kunmap_local(ptr);
+ }
+}
+
/*
* To accurately reflect hot un/plug changes of CPU and Memory resources
* (including onling and offlining of those resources), the relevant
@@ -702,22 +724,7 @@ static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int cpu,
* is allocated. Find the segment containing the elfcorehdr,
* if not already found.
*/
- if (image->elfcorehdr_index < 0) {
- unsigned long mem;
- unsigned char *ptr;
- unsigned int n;
-
- for (n = 0; n < image->nr_segments; n++) {
- mem = image->segment[n].mem;
- ptr = kmap_local_page(pfn_to_page(mem >> PAGE_SHIFT));
- if (ptr) {
- /* The segment containing elfcorehdr */
- if (memcmp(ptr, ELFMAG, SELFMAG) == 0)
- image->elfcorehdr_index = (int)n;
- kunmap_local(ptr);
- }
- }
- }
+ crash_find_elfcorehdr(image);
if (image->elfcorehdr_index < 0) {
pr_err("unable to locate elfcorehdr segment");
@@ -747,6 +754,25 @@ static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int cpu,
crash_hotplug_unlock();
}
+void crash_hotplug_prepare_elfcorehdr(struct kimage *image)
+{
+ if (!image || !image->hotplug_support || image->file_mode)
+ return;
+
+ crash_find_elfcorehdr(image);
+ if (image->elfcorehdr_index < 0)
+ return;
+
+ /*
+ * kexec_load() images are not normalized at load, so do it here while
+ * the lock is still free to take. hp_action is KEXEC_CRASH_HP_NONE,
+ * which the arch handler treats as "just rebuild the elfcorehdr".
+ */
+ lock_device_hotplug();
+ arch_crash_handle_hotplug_event(image, NULL);
+ unlock_device_hotplug();
+}
+
static int crash_memhp_notifier(struct notifier_block *nb, unsigned long val, void *arg)
{
switch (val) {
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 90756dc6339b..ea9ba00bc786 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -166,6 +166,10 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments,
/* Install the new kernel and uninstall the old */
image = xchg(dest_image, image);
+#ifdef CONFIG_CRASH_HOTPLUG
+ if ((flags & KEXEC_ON_CRASH) && kexec_crash_image)
+ crash_hotplug_prepare_elfcorehdr(kexec_crash_image);
+#endif
out:
#ifdef CONFIG_CRASH_DUMP
if ((flags & KEXEC_ON_CRASH) && kexec_crash_image)
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 11/17] crash: Normalize the kexec_load elfcorehdr at load time
2026-09-18 10:04 ` [PATCH v5 11/17] crash: Normalize the kexec_load elfcorehdr at load time Jinjie Ruan
@ 2026-09-18 10:27 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:27 UTC (permalink / raw)
To: baoquan.he, gregkh, ruirui.yang, npiggin, liukexin, dave.hansen,
mclapinski, ritesh.list, takahiro.akashi, x86, linux-kernel,
will, pratyush, coxu, mingo, zhangtianyang, linux-fsdevel,
sourabhjain, hpa, rafael, graf, ruanjinjie, jbouron, yeoreum.yun,
hbathini, chenhuacai, akpm, lizhengyu3, chleroy, adityag, dakr,
piliu, pasha.tatashin, linux-arm-kernel, linux-mm, ardb, leitao,
catalin.marinas, kees, thuth, blum, kas, maddy, james.morse,
tglx, bp
Cc: kexec
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kexec: elfcorehdr_updated in struct kimage is write-only and unused
--
commit 463b7b7692d8e96dc1be8ffaed1b6d0c8d298c9f
Author: Jinjie Ruan <ruanjinjie@huawei.com>
crash: Normalize the kexec_load elfcorehdr at load time
This commit changes kexec_load to normalize the elfcorehdr at load time
instead of waiting for the first crash hotplug event. By doing this while
the device_hotplug_lock can be safely taken, it allows hotplug paths to
skip CPU events safely and avoid racing with memory hotplug.
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 3c9f4fbbe7ff0..f34fa8dba0288 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -457,9 +457,8 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
> * possible CPUs, there is no need to update the elfcorehdr
> * for additional CPU changes.
> */
> - if ((image->file_mode || image->elfcorehdr_updated) &&
> - ((image->hp_action == KEXEC_CRASH_HP_ADD_CPU) ||
> - (image->hp_action == KEXEC_CRASH_HP_REMOVE_CPU)))
> + if (image->hp_action == KEXEC_CRASH_HP_ADD_CPU ||
> + image->hp_action == KEXEC_CRASH_HP_REMOVE_CPU)
> return;
[Severity: Low]
Does this leave elfcorehdr_updated as a write-only and unused field?
Since this patch removes the last reader of image->elfcorehdr_updated,
the field is now only written to in crash_handle_hotplug_event() and
initialized in kernel/kexec_core.c:
kernel/crash_core.c:crash_handle_hotplug_event() {
...
image->hp_action = KEXEC_CRASH_HP_NONE;
image->elfcorehdr_updated = true;
...
}
Should the elfcorehdr_updated field be completely removed from struct kimage
in include/linux/kexec.h along with its assignments to avoid dead code and
structure overhead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=11
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 12/17] crash: Fix TOCTOU race in crash memory range collection
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (10 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 11/17] crash: Normalize the kexec_load elfcorehdr at load time Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:34 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 13/17] crash: Assert device_hotplug_lock in crash_get_memory_ranges_nolock() Jinjie Ruan
` (5 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
The crash kernel ELF core header construction counts system memory
ranges via `arch_get_system_nr_ranges()`, allocates the crash_mem
buffer, and then populates it via `arch_crash_populate_cmem()`.
This sequence has a time-of-check-to-time-of-use (TOCTOU) race with
memory hotplug: a concurrent hotplug event between the count
and populate steps can increase the number of ranges beyond the allocated
capacity, causing an out-of-bounds write. If the event triggers
memblock_double_array(), the memblock array can be freed and reallocated
during iteration, leading to a use-after-free.
Protect the entire range collection with device_hotplug_lock. Since
the hotplug notification path already holds that lock, add a lockless
helper, crash_get_memory_ranges_nolock(), for use there. The regular
crash_get_memory_ranges() acquires the lock and calls the helper.
Cc: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Dave Young <ruirui.yang@linux.dev>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Will Deacon <will@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: Huacai Chen <chenhuacai@kernel.org>
Fixes: 8d5f894a3108 ("x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer")
Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support")
Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic")
Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file")
Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/x86/kernel/crash.c | 9 ++++++++-
include/linux/crash_core.h | 2 +-
kernel/crash_core.c | 28 +++++++++++++++++++++++++++-
3 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index f34fa8dba028..7fa139725514 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -447,6 +447,7 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
*/
void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
{
+ struct crash_mem *cmem = NULL;
unsigned long mem, memsz;
unsigned long elfsz = 0;
void *elfbuf = NULL;
@@ -461,11 +462,16 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
image->hp_action == KEXEC_CRASH_HP_REMOVE_CPU)
return;
+ if (crash_get_memory_ranges_nolock(&cmem)) {
+ pr_err("Failed to get crash mem range\n");
+ goto out;
+ }
+
/*
* 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_elf64_headers(cmem, IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz)) {
pr_err("unable to create new elfcorehdr");
goto out;
}
@@ -501,6 +507,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
pr_debug("updated elfcorehdr\n");
out:
+ kvfree(cmem);
vfree(elfbuf);
}
#endif
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index a740757dff35..1296a9b29974 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -63,7 +63,7 @@ extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_ma
extern 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);
-int crash_get_memory_ranges(struct crash_mem **mem_ranges);
+int crash_get_memory_ranges_nolock(struct crash_mem **mem_ranges);
struct kimage;
struct kexec_segment;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 47a4579eb97e..760ca9822a13 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -7,6 +7,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/buildid.h>
+#include <linux/device.h>
#include <linux/init.h>
#include <linux/utsname.h>
#include <linux/vmalloc.h>
@@ -317,7 +318,21 @@ int crash_exclude_core_ranges(struct crash_mem **cmem)
return 0;
}
-int crash_get_memory_ranges(struct crash_mem **mem_ranges)
+/**
+ * crash_get_memory_ranges_nolock - Collect crash kernel memory ranges
+ * @mem_ranges: Output parameter for the allocated crash_mem structure
+ *
+ * Gathers the system memory ranges to be included in the crash kernel's
+ * ELF core header, excluding the crashkernel reserved region and other
+ * architecture-specific areas.
+ *
+ * Context: Caller must hold device_hotplug_lock.
+ *
+ * Return: 0 on success, in which case *@mem_ranges points to a newly
+ * allocated struct crash_mem that the caller must free with kvfree().
+ * Returns a negative error code on failure.
+ */
+int crash_get_memory_ranges_nolock(struct crash_mem **mem_ranges)
{
unsigned int max_nr_ranges;
struct crash_mem *cmem;
@@ -351,6 +366,17 @@ int crash_get_memory_ranges(struct crash_mem **mem_ranges)
return ret;
}
+static int crash_get_memory_ranges(struct crash_mem **mem_ranges)
+{
+ int ret;
+
+ lock_device_hotplug();
+ ret = crash_get_memory_ranges_nolock(mem_ranges);
+ unlock_device_hotplug();
+
+ return ret;
+}
+
int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
unsigned long *nr_mem_ranges)
{
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 12/17] crash: Fix TOCTOU race in crash memory range collection
2026-09-18 10:04 ` [PATCH v5 12/17] crash: Fix TOCTOU race in crash memory range collection Jinjie Ruan
@ 2026-09-18 10:34 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:34 UTC (permalink / raw)
To: vishal.l.verma, linux-fsdevel, jbouron, linux-mm, sshegde, bp,
maqianga, mpe, kas, gregkh, chao.gao, mingo, kernel, Jinjie Ruan,
chenhuacai, seanjc, ritesh.list, pratyush, tglx, pasha.tatashin,
yeoreum.yun, gshan, chleroy, liukexin, thuth, eric.devolder,
linux-kernel, kees, dakr, mark.rutland, x86, leitao, blum,
catalin.marinas, zhangtianyang, me, mclapinski, palmer,
loongarch, ruanjinjie, rafael, will, npiggin, dave.hansen, rppt,
hpa, james.morse, tangyouling, linuxppc-dev, takahiro.akashi,
baoquan.he, lizhengyu3, maddy, coxu, linux-arm-kernel,
guodongtai, hbathini, ruirui.yang, adityag, graf, akpm,
sourabhjain, driver-core, piliu, ardb, robh, bgwin
Cc: kexec
> The crash kernel ELF core header construction counts system memory
> ranges via `arch_get_system_nr_ranges()`, allocates the crash_mem
> buffer, and then populates it via `arch_crash_populate_cmem()`.
> This sequence has a time-of-check-to-time-of-use (TOCTOU) race with
> memory hotplug: a concurrent hotplug event between the count
> and populate steps can increase the number of ranges beyond the allocated
> capacity, causing an out-of-bounds write. If the event triggers
> memblock_double_array(), the memblock array can be freed and reallocated
> during iteration, leading to a use-after-free.
>
> Protect the entire range collection with device_hotplug_lock. Since
> the hotplug notification path already holds that lock, add a lockless
> helper, crash_get_memory_ranges_nolock(), for use there. The regular
> crash_get_memory_ranges() acquires the lock and calls the helper.
>
> [ ... ]
> Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support")
> Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic")
> Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file")
> Link: https://sashiko.dev/#/patchset/20260729031235.2840255-1-ruanjinjie%40huawei.com
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=12
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 13/17] crash: Assert device_hotplug_lock in crash_get_memory_ranges_nolock()
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (11 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 12/17] crash: Fix TOCTOU race in crash memory range collection Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:26 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 14/17] elf: Introduce elf64_phdr_size() helper Jinjie Ruan
` (4 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
crash_get_memory_ranges_nolock() walks memblock, which memory hotplug
modifies under device_hotplug_lock. A caller that does not hold the lock
can race with memblock_double_array() and iterate a freed regions array.
Add device_hotplug_lock_assert_held() and call it at the top of the
function so that such callers are caught by lockdep.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
drivers/base/core.c | 5 +++++
include/linux/device.h | 1 +
kernel/crash_core.c | 7 +++++++
3 files changed, 13 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4c0c373998a1..c04adc457a96 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2420,6 +2420,11 @@ void unlock_device_hotplug(void)
mutex_unlock(&device_hotplug_lock);
}
+void device_hotplug_lock_assert_held(void)
+{
+ lockdep_assert_held(&device_hotplug_lock);
+}
+
int lock_device_hotplug_sysfs(void)
{
if (mutex_trylock(&device_hotplug_lock))
diff --git a/include/linux/device.h b/include/linux/device.h
index aee79fd6b32b..9cca8c8bd372 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1261,6 +1261,7 @@ do { \
void lock_device_hotplug(void);
void unlock_device_hotplug(void);
int lock_device_hotplug_sysfs(void);
+void device_hotplug_lock_assert_held(void);
int device_offline(struct device *dev);
int device_online(struct device *dev);
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 760ca9822a13..852a5f51d472 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -338,6 +338,13 @@ int crash_get_memory_ranges_nolock(struct crash_mem **mem_ranges)
struct crash_mem *cmem;
int ret;
+ /*
+ * Callers must serialize against memory hotplug by holding
+ * device_hotplug_lock, otherwise the memblock iteration below can
+ * race with memblock_double_array() and read freed memory.
+ */
+ device_hotplug_lock_assert_held();
+
max_nr_ranges = arch_get_system_nr_ranges();
if (!max_nr_ranges)
return -ENOMEM;
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 13/17] crash: Assert device_hotplug_lock in crash_get_memory_ranges_nolock()
2026-09-18 10:04 ` [PATCH v5 13/17] crash: Assert device_hotplug_lock in crash_get_memory_ranges_nolock() Jinjie Ruan
@ 2026-09-18 10:26 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:26 UTC (permalink / raw)
To: akpm, me, takahiro.akashi, linuxppc-dev, driver-core, maddy, hpa,
yeoreum.yun, lizhengyu3, loongarch, mark.rutland, blum, gregkh,
rafael, kas, pasha.tatashin, linux-kernel, chenhuacai, palmer,
robh, ardb, linux-arm-kernel, seanjc, tglx, thuth, tangyouling,
adityag, x86, pratyush, kernel, liukexin, bgwin, ritesh.list,
will, dakr, chao.gao, sshegde, ruirui.yang, zhangtianyang,
hbathini, jbouron, sourabhjain, kees, gshan, mclapinski, rppt,
guodongtai, coxu, piliu, ruanjinjie, maqianga, mingo, linux-mm,
mpe, chleroy, graf, linux-fsdevel, bp, eric.devolder,
vishal.l.verma, james.morse, catalin.marinas, npiggin,
baoquan.he, Jinjie Ruan, dave.hansen, leitao
Cc: kexec
> crash_get_memory_ranges_nolock() walks memblock, which memory hotplug
> modifies under device_hotplug_lock. A caller that does not hold the lock
> can race with memblock_double_array() and iterate a freed regions array.
>
> Add device_hotplug_lock_assert_held() and call it at the top of the
> function so that such callers are caught by lockdep.
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=13
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 14/17] elf: Introduce elf64_phdr_size() helper
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (12 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 13/17] crash: Assert device_hotplug_lock in crash_get_memory_ranges_nolock() Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:25 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 15/17] crash: Introduce crash_extra_elfcorehdr_size() helper Jinjie Ruan
` (3 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
Add a common helper to compute the total size of an ELF64 header
(Ehdr + program headers) from the number of program headers.
Replace open-coded calculations in powerpc, x86, vmcore,
and crash_core.
On ppc64, struct elfhdr maps to elf64_hdr, so the powerpc change
is a pure cleanup.
No functional change intended.
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Dave Young <ruirui.yang@linux.dev>
Cc: Kees Cook <kees@kernel.org>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/kexec/crash.c | 2 +-
arch/powerpc/platforms/powernv/opal-core.c | 3 +--
arch/x86/kernel/crash.c | 3 +--
fs/proc/vmcore.c | 6 ++----
include/linux/elf.h | 4 ++++
kernel/crash_core.c | 2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index 8ede33740fc0..0cdc64da35b8 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -478,7 +478,7 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
phdr_cnt += CONFIG_CRASH_MAX_MEMORY_RANGES;
- return sizeof(struct elfhdr) + (phdr_cnt * sizeof(Elf64_Phdr));
+ return elf64_phdr_size(phdr_cnt);
}
/**
diff --git a/arch/powerpc/platforms/powernv/opal-core.c b/arch/powerpc/platforms/powernv/opal-core.c
index 32662d30d70f..fc0aad61504b 100644
--- a/arch/powerpc/platforms/powernv/opal-core.c
+++ b/arch/powerpc/platforms/powernv/opal-core.c
@@ -309,8 +309,7 @@ static int __init create_opalcore(void)
char *bufp;
/* Get size of header & CPU notes for OPAL core */
- hdr_size = (sizeof(Elf64_Ehdr) +
- ((oc_conf->ptload_cnt + 1) * sizeof(Elf64_Phdr)));
+ hdr_size = elf64_phdr_size(oc_conf->ptload_cnt + 1);
cpu_notes_size = ((oc_conf->num_cpus * (CRASH_CORE_NOTE_HEAD_BYTES +
CRASH_CORE_NOTE_NAME_BYTES +
CRASH_CORE_NOTE_DESC_BYTES)) +
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 7fa139725514..6711f8bf1db3 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -374,8 +374,7 @@ int crash_load_segments(struct kimage *image)
pnum += 2 + CONFIG_NR_CPUS_DEFAULT;
if (pnum < (unsigned long)PN_XNUM) {
- kbuf.memsz = pnum * sizeof(Elf64_Phdr);
- kbuf.memsz += sizeof(Elf64_Ehdr);
+ kbuf.memsz = elf64_phdr_size(pnum);
image->elfcorehdr_index = image->nr_segments;
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 44d15436439f..ff324969d798 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -1238,8 +1238,7 @@ static int __init parse_crash_elf64_headers(void)
}
/* Read in all elf headers. */
- elfcorebuf_sz_orig = sizeof(Elf64_Ehdr) +
- ehdr.e_phnum * sizeof(Elf64_Phdr);
+ elfcorebuf_sz_orig = elf64_phdr_size(ehdr.e_phnum);
elfcorebuf_sz = elfcorebuf_sz_orig;
elfcorebuf = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
get_order(elfcorebuf_sz_orig));
@@ -1605,8 +1604,7 @@ static int vmcore_add_device_ram_elf64(struct list_head *list, size_t count)
}
/* elfcorebuf_sz must always cover full pages. */
- new_size = sizeof(Elf64_Ehdr) +
- (ehdr->e_phnum + count) * sizeof(Elf64_Phdr);
+ new_size = elf64_phdr_size(ehdr->e_phnum + count);
new_size = roundup(new_size, PAGE_SIZE);
/*
diff --git a/include/linux/elf.h b/include/linux/elf.h
index 5c402788da19..400f58a13d92 100644
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -109,4 +109,8 @@ static inline int arch_elf_adjust_prot(int prot,
}
#endif
+static inline unsigned long elf64_phdr_size(unsigned long phdr_cnt)
+{
+ return phdr_cnt * sizeof(Elf64_Phdr) + sizeof(Elf64_Ehdr);
+}
#endif /* _LINUX_ELF_H */
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 852a5f51d472..8e30ae107a7c 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -193,7 +193,7 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
*/
nr_phdr++;
- elf_sz = sizeof(Elf64_Ehdr) + nr_phdr * sizeof(Elf64_Phdr);
+ elf_sz = elf64_phdr_size(nr_phdr);
elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
buf = vzalloc(elf_sz);
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 14/17] elf: Introduce elf64_phdr_size() helper
2026-09-18 10:04 ` [PATCH v5 14/17] elf: Introduce elf64_phdr_size() helper Jinjie Ruan
@ 2026-09-18 10:25 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:25 UTC (permalink / raw)
To: Jinjie Ruan, lizhengyu3, dave.hansen, mark.rutland, bgwin,
npiggin, mingo, mclapinski, thuth, ruirui.yang, sourabhjain,
linuxppc-dev, catalin.marinas, dakr, linux-kernel,
vishal.l.verma, pasha.tatashin, robh, sshegde, chao.gao, rppt,
seanjc, chleroy, liukexin, linux-mm, takahiro.akashi, piliu,
akpm, pratyush, ruanjinjie, kees, hpa, rafael, ritesh.list, blum,
linux-arm-kernel, coxu, maddy, eric.devolder, palmer, tglx,
adityag, kas, chenhuacai, yeoreum.yun, maqianga, gshan,
guodongtai, gregkh, x86, zhangtianyang, jbouron, bp, tangyouling,
loongarch, james.morse, ardb, mpe, leitao, will, baoquan.he,
hbathini, me, graf, linux-fsdevel, kernel, driver-core
Cc: kexec
> Add a common helper to compute the total size of an ELF64 header
> (Ehdr + program headers) from the number of program headers.
> Replace open-coded calculations in powerpc, x86, vmcore,
> and crash_core.
>
> On ppc64, struct elfhdr maps to elf64_hdr, so the powerpc change
> is a pure cleanup.
>
> No functional change intended.
>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Dave Young <ruirui.yang@linux.dev>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=14
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 15/17] crash: Introduce crash_extra_elfcorehdr_size() helper
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (13 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 14/17] elf: Introduce elf64_phdr_size() helper Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:31 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 16/17] arm64: kexec_file: Simplify load_other_segments() Jinjie Ruan
` (2 subsequent siblings)
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
Extract the elfcorehdr extra space calculation from powerpc into a
generic helper crash_extra_elfcorehdr_size() for use by other
architectures like arm64.
Strengthen the original powerpc check: instead of only checking
the loose CONFIG_CRASH_MAX_MEMORY_RANGES, the new helper enforces
a strict compile-time BUILD_BUG_ON() to guarantee that the absolute
maximum theoretical number of ELF Program Headers will never exceed
the ELF physical limit of PN_XNUM. This ensures absolute safety across
all architectures with zero runtime overhead.
The helper also provides a zero-size stub when crash memory hotplug
is disabled.
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Dave Young <ruirui.yang@linux.dev>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/kexec/file_load_64.c | 15 +--------------
include/linux/crash_core.h | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
index bd80c5fb1b1f..d3512c85ea83 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -374,19 +374,6 @@ static int load_backup_segment(struct kimage *image, struct kexec_buf *kbuf)
return 0;
}
-static unsigned int kdump_extra_elfcorehdr_size(struct crash_mem *cmem)
-{
-#if defined(CONFIG_CRASH_HOTPLUG) && defined(CONFIG_MEMORY_HOTPLUG)
- if (CONFIG_CRASH_MAX_MEMORY_RANGES > (unsigned int)PN_XNUM)
- pr_warn("Number of Phdrs %u exceeds max\n", CONFIG_CRASH_MAX_MEMORY_RANGES);
- else if (cmem->nr_ranges >= CONFIG_CRASH_MAX_MEMORY_RANGES)
- pr_warn("Configured crash mem ranges may not be enough\n");
- else
- return (CONFIG_CRASH_MAX_MEMORY_RANGES - cmem->nr_ranges) * sizeof(Elf64_Phdr);
-#endif
- return 0;
-}
-
/**
* load_elfcorehdr_segment - Setup crash memory ranges and initialize elfcorehdr
* segment needed to load kdump kernel.
@@ -424,7 +411,7 @@ static int load_elfcorehdr_segment(struct kimage *image, struct kexec_buf *kbuf)
* Account for extra space required to accommodate additional memory
* ranges in elfcorehdr due to memory hotplug events.
*/
- kbuf->memsz = headers_sz + kdump_extra_elfcorehdr_size(cmem);
+ kbuf->memsz = headers_sz + crash_extra_elfcorehdr_size(cmem->nr_ranges);
kbuf->top_down = false;
ret = kexec_add_buffer(kbuf);
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 1296a9b29974..aee2449f343b 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -107,4 +107,24 @@ ssize_t dm_crypt_keys_read(char *buf, size_t count, u64 *ppos);
static inline int crash_load_dm_crypt_keys(struct kimage *image) {return 0; }
#endif
+#if defined(CONFIG_CRASH_HOTPLUG) && defined(CONFIG_MEMORY_HOTPLUG)
+static inline unsigned int crash_extra_elfcorehdr_size(unsigned int nr_mem_ranges)
+{
+ BUILD_BUG_ON((2 + CONFIG_NR_CPUS + CONFIG_CRASH_MAX_MEMORY_RANGES) >=
+ (unsigned int)PN_XNUM);
+
+ if (nr_mem_ranges >= CONFIG_CRASH_MAX_MEMORY_RANGES) {
+ pr_warn_once("Configured crash mem ranges may not be enough\n");
+ return 0;
+ }
+
+ return (CONFIG_CRASH_MAX_MEMORY_RANGES - nr_mem_ranges) * sizeof(Elf64_Phdr);
+}
+#else
+static inline unsigned int crash_extra_elfcorehdr_size(unsigned int nr_mem_ranges)
+{
+ return 0;
+}
+#endif
+
#endif /* LINUX_CRASH_CORE_H */
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 15/17] crash: Introduce crash_extra_elfcorehdr_size() helper
2026-09-18 10:04 ` [PATCH v5 15/17] crash: Introduce crash_extra_elfcorehdr_size() helper Jinjie Ruan
@ 2026-09-18 10:31 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:31 UTC (permalink / raw)
To: hpa, robh, leitao, linuxppc-dev, tglx, rafael, thuth, dakr,
driver-core, kas, coxu, linux-fsdevel, ruirui.yang, dave.hansen,
kees, tangyouling, yeoreum.yun, linux-mm, rppt, will,
eric.devolder, ardb, linux-kernel, chao.gao, sshegde, x86,
hbathini, liukexin, mingo, mclapinski, bgwin, james.morse,
pratyush, pasha.tatashin, loongarch, kernel, adityag, npiggin,
vishal.l.verma, akpm, ruanjinjie, lizhengyu3, linux-arm-kernel,
Jinjie Ruan, blum, takahiro.akashi, palmer, gshan, maqianga,
mark.rutland, baoquan.he, jbouron, zhangtianyang, ritesh.list,
me, mpe, chleroy, piliu, catalin.marinas, gregkh, graf, bp,
chenhuacai, sourabhjain, seanjc, guodongtai, maddy
Cc: kexec
> Extract the elfcorehdr extra space calculation from powerpc into a
> generic helper crash_extra_elfcorehdr_size() for use by other
> architectures like arm64.
>
> Strengthen the original powerpc check: instead of only checking
> the loose CONFIG_CRASH_MAX_MEMORY_RANGES, the new helper enforces
> a strict compile-time BUILD_BUG_ON() to guarantee that the absolute
> maximum theoretical number of ELF Program Headers will never exceed
> the ELF physical limit of PN_XNUM. This ensures absolute safety across
> all architectures with zero runtime overhead.
>
> The helper also provides a zero-size stub when crash memory hotplug
> is disabled.
>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Baoquan He <baoquan.he@linux.dev>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Dave Young <ruirui.yang@linux.dev>
> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=15
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 16/17] arm64: kexec_file: Simplify load_other_segments()
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (14 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 15/17] crash: Introduce crash_extra_elfcorehdr_size() helper Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:27 ` sashiko-bot
2026-09-18 10:04 ` [PATCH v5 17/17] arm64: crash: Add crash hotplug support Jinjie Ruan
2026-09-18 10:41 ` [PATCH v5 00/17] crash: Rework and add arm64 " Breno Leitao
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
Use `kbuf` fields directly in crash_prepare_headers() to eliminate
the local variables "headers" and "headers_sz"..
Advance the assignment to image->elf_headers before
calling kexec_add_buffer(). If kexec_add_buffer() fails, the explicit
vfree() in the error path can be removed, as the global infrastructure
in arch_kimage_file_post_load_cleanup() will handle the cleanup.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Breno Leitao <leitao@debian.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/machine_kexec_file.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 2f750e5f4fcc..3d907f8ee594 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -89,36 +89,30 @@ int load_other_segments(struct kimage *image,
kbuf.buf_min = kernel_load_addr + kernel_size;
#ifdef CONFIG_CRASH_DUMP
- /* load elf core header */
- void *headers;
- unsigned long headers_sz;
if (image->type == KEXEC_TYPE_CRASH) {
- ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
+ ret = crash_prepare_headers(true, &kbuf.buffer, &kbuf.bufsz, NULL);
if (ret) {
pr_err("Preparing elf core header failed\n");
goto out_err;
}
- kbuf.buffer = headers;
- kbuf.bufsz = headers_sz;
+ if (unlikely(image->elf_headers))
+ vfree(image->elf_headers);
+
+ image->elf_headers = kbuf.buffer;
+ image->elf_headers_sz = kbuf.bufsz;
+
kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
- kbuf.memsz = headers_sz;
+ kbuf.memsz = kbuf.bufsz;
kbuf.buf_align = SZ_64K; /* largest supported page size */
kbuf.buf_max = ULONG_MAX;
kbuf.top_down = true;
ret = kexec_add_buffer(&kbuf);
- if (ret) {
- vfree(headers);
+ if (ret)
goto out_err;
- }
-
- if (unlikely(image->elf_headers))
- vfree(image->elf_headers);
- image->elf_headers = headers;
image->elf_load_addr = kbuf.mem;
- image->elf_headers_sz = headers_sz;
kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 16/17] arm64: kexec_file: Simplify load_other_segments()
2026-09-18 10:04 ` [PATCH v5 16/17] arm64: kexec_file: Simplify load_other_segments() Jinjie Ruan
@ 2026-09-18 10:27 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:27 UTC (permalink / raw)
To: npiggin, vishal.l.verma, kernel, rafael, james.morse,
tangyouling, sourabhjain, leitao, coxu, palmer, linux-arm-kernel,
blum, baoquan.he, x86, jbouron, lizhengyu3, hbathini, seanjc,
dakr, sshegde, pasha.tatashin, gshan, ritesh.list, piliu,
chao.gao, driver-core, kees, kas, bp, mingo, bgwin, linux-kernel,
chenhuacai, linux-fsdevel, maqianga, zhangtianyang,
catalin.marinas, maddy, akpm, yeoreum.yun, loongarch,
ruirui.yang, graf, takahiro.akashi, mpe, g
Cc: kexec
> Use `kbuf` fields directly in crash_prepare_headers() to eliminate
> the local variables "headers" and "headers_sz"..
>
> Advance the assignment to image->elf_headers before
> calling kexec_add_buffer(). If kexec_add_buffer() fails, the explicit
> vfree() in the error path can be removed, as the global infrastructure
> in arch_kimage_file_post_load_cleanup() will handle the cleanup.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Breno Leitao <leitao@debian.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=16
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5 17/17] arm64: crash: Add crash hotplug support
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (15 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 16/17] arm64: kexec_file: Simplify load_other_segments() Jinjie Ruan
@ 2026-09-18 10:04 ` Jinjie Ruan
2026-09-18 10:36 ` sashiko-bot
2026-09-18 10:41 ` [PATCH v5 00/17] crash: Rework and add arm64 " Breno Leitao
17 siblings, 1 reply; 36+ messages in thread
From: Jinjie Ruan @ 2026-09-18 10:04 UTC (permalink / raw)
To: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, ruanjinjie,
gshan, ardb, james.morse, leitao, yeoreum.yun, sourabhjain, robh,
coxu, tangyouling, liukexin, guodongtai, maqianga, zhangtianyang,
blum, adityag, chao.gao, kas, vishal.l.verma, seanjc, piliu,
jbouron, me, mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
When CPU or memory hotplug events occur, the elfcorehdr in the kdump
image becomes stale, potentially leading to incomplete crash dumps.
Currently, userspace udev rules reload the entire kdump image upon such
events, which is inefficient and leaves kdump inactive for a long time.
Commit 247262756121 ("crash: add generic infrastructure for crash hotplug
support") introduced a kernel mechanism to update only the elfcorehdr.
This patch enables that support for arm64.
On arm64, only memory hotplug events require elfcorehdr updates:
- Physical CPU hotplug is not supported.
- For ACPI based vCPU hotplug [1], the elfcorehdr is built using
for_each_possible_cpu(), so no update is needed.
The patch:
- Adds CONFIG_ARCH_SUPPORTS_CRASH_HOTPLUG (default y).
- Implements following arch functions to handle memory hotplug:
1. arch_crash_hotplug_support()
2. arch_crash_get_elfcorehdr_size()
3. arch_crash_handle_hotplug_event()
- Moves arch_get_system_nr_ranges() and arch_crash_populate_cmem()
from machine_kexec_file.c to crash.c for crash hotplug reuse.
Follows the approach of x86 commit ea53ad9cf73b ("x86/crash: add x86 crash
hotplug support") and powerpc commit b741092d5976 ("powerpc/crash: add
crash CPU hotplug support").
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Breno Leitao <leitao@debian.org>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Thomas Huth <thuth@redhat.com>
[1]: https://lore.kernel.org/all/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/kexec.h | 11 ++
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/crash.c | 171 +++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec_file.c | 42 ++----
5 files changed, 196 insertions(+), 33 deletions(-)
create mode 100644 arch/arm64/kernel/crash.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b5a51b0ef944..96de2660b1cb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1720,6 +1720,9 @@ config ARCH_DEFAULT_CRASH_DUMP
config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
def_bool CRASH_RESERVE
+config ARCH_SUPPORTS_CRASH_HOTPLUG
+ def_bool y
+
config TRANS_TABLE
def_bool y
depends on HIBERNATION || KEXEC_CORE
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 892e5bebda95..f165c094b32e 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -130,6 +130,17 @@ extern int load_other_segments(struct kimage *image,
char *cmdline);
#endif
+#ifdef CONFIG_CRASH_HOTPLUG
+void arch_crash_handle_hotplug_event(struct kimage *image, void *arg);
+#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event
+
+int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_flags);
+#define arch_crash_hotplug_support arch_crash_hotplug_support
+
+unsigned int arch_crash_get_elfcorehdr_size(void);
+#define crash_get_elfcorehdr_size arch_crash_get_elfcorehdr_size
+#endif
+
#endif /* __ASSEMBLER__ */
#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index d2690c3ec528..9bbac452994c 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -64,7 +64,7 @@ obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o \
obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o
obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
+obj-$(CONFIG_CRASH_DUMP) += crash_dump.o crash.o
obj-$(CONFIG_VMCORE_INFO) += vmcore_info.o
obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
obj-$(CONFIG_ARM64_PTR_AUTH) += pointer_auth.o
diff --git a/arch/arm64/kernel/crash.c b/arch/arm64/kernel/crash.c
new file mode 100644
index 000000000000..08dc9b952498
--- /dev/null
+++ b/arch/arm64/kernel/crash.c
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Architecture specific functions for kexec based crash dumps.
+ */
+
+#define pr_fmt(fmt) "crash hp: " fmt
+
+#include <linux/cacheflush.h>
+#include <linux/elf.h>
+#include <linux/kexec.h>
+#include <linux/memblock.h>
+#include <linux/memory.h>
+#include <linux/vmalloc.h>
+
+#include <asm/kexec.h>
+
+#if defined(CONFIG_KEXEC_FILE) || defined(CONFIG_CRASH_HOTPLUG)
+unsigned int arch_get_system_nr_ranges(void)
+{
+ unsigned int nr_ranges = 2 + crashk_cma_cnt; /* for exclusion of crashkernel region */
+ phys_addr_t start, end;
+ u64 i;
+
+ for_each_mem_range(i, &start, &end)
+ nr_ranges++;
+
+ /* Memory hot-unplug may cause range split. So add an extra slot here. */
+ if (IS_ENABLED(CONFIG_CRASH_HOTPLUG))
+ nr_ranges++;
+
+ return nr_ranges;
+}
+
+int arch_crash_populate_cmem(struct crash_mem *cmem)
+{
+ phys_addr_t start, end;
+ u64 i;
+
+ for_each_mem_range(i, &start, &end) {
+ cmem->ranges[cmem->nr_ranges].start = start;
+ cmem->ranges[cmem->nr_ranges].end = end - 1;
+ cmem->nr_ranges++;
+ }
+
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_CRASH_HOTPLUG
+int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_flags)
+{
+#ifdef CONFIG_KEXEC_FILE
+ if (image->file_mode)
+ return 1;
+#endif
+ /*
+ * For kexec_load syscall, crash hotplug support requires
+ * KEXEC_CRASH_HOTPLUG_SUPPORT flag to be passed by userspace.
+ */
+ return kexec_flags & KEXEC_CRASH_HOTPLUG_SUPPORT;
+}
+
+unsigned int arch_crash_get_elfcorehdr_size(void)
+{
+ unsigned long phdr_cnt;
+
+ /* A program header for possible CPUs, vmcoreinfo and kernel_map */
+ phdr_cnt = 2 + num_possible_cpus();
+ if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+ phdr_cnt += CONFIG_CRASH_MAX_MEMORY_RANGES;
+
+ return elf64_phdr_size(phdr_cnt);
+}
+
+/**
+ * update_crash_elfcorehdr() - Recreate the elfcorehdr and replace it with old
+ * elfcorehdr in the kexec segment array.
+ * @image: the active struct kimage
+ * @mn: struct memory_notify data handler
+ */
+static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *mn)
+{
+ void *elfbuf = NULL, *old_elfcorehdr;
+ unsigned long mem, memsz, elfsz = 0;
+ struct crash_mem *cmem = NULL;
+ u64 start, end;
+ int ret;
+
+ ret = crash_get_memory_ranges_nolock(&cmem);
+ if (ret) {
+ pr_err("Failed to get crash memory ranges.\n");
+ goto out;
+ }
+
+ /*
+ * The hot unplugged memory is part of crash memory ranges,
+ * remove it here.
+ */
+ if (image->hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY) {
+ start = PFN_PHYS(mn->start_pfn);
+ end = start + PFN_PHYS(mn->nr_pages) - 1;
+
+ ret = crash_exclude_mem_range(cmem, start, end);
+ if (ret) {
+ pr_err("Failed to remove hot-unplugged memory from crash memory ranges.\n");
+ goto out;
+ }
+ }
+
+ /*
+ * Create the new elfcorehdr reflecting the changes to CPU and/or
+ * memory resources.
+ */
+ ret = crash_prepare_elf64_headers(cmem, true, &elfbuf, &elfsz);
+ if (ret) {
+ pr_err("Failed to create new elfcorehdr");
+ goto out;
+ }
+
+ /*
+ * Obtain address and size of the elfcorehdr segment, and
+ * check it against the new elfcorehdr buffer.
+ */
+ mem = image->segment[image->elfcorehdr_index].mem;
+ memsz = image->segment[image->elfcorehdr_index].memsz;
+ if (elfsz > memsz) {
+ pr_err("update elfcorehdr elfsz %lu > memsz %lu",
+ elfsz, memsz);
+ goto out;
+ }
+
+ /* Copy new elfcorehdr over the old elfcorehdr at destination. */
+ old_elfcorehdr = phys_to_virt(mem);
+
+ /*
+ * Temporarily invalidate the crash image while the
+ * elfcorehdr is updated.
+ */
+ xchg(&kexec_crash_image, NULL);
+ memcpy(old_elfcorehdr, elfbuf, elfsz);
+ dcache_clean_inval_poc((unsigned long)old_elfcorehdr,
+ (unsigned long)(old_elfcorehdr + elfsz));
+ xchg(&kexec_crash_image, image);
+ pr_debug("updated elfcorehdr\n");
+
+out:
+ kvfree(cmem);
+ vfree(elfbuf);
+}
+
+/**
+ * arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes
+ * @image: a pointer to kexec_crash_image
+ * @arg: struct memory_notify handler for memory hotplug case and
+ * NULL for CPU hotplug case.
+ *
+ * Update the kdump image based on the type of hotplug event:
+ * - CPU add and remove: No action is needed.
+ * - Memory add/remove: Update the elfcorehdr to reflect the current memory layout.
+ *
+ * Prepare the new elfcorehdr and replace the existing elfcorehdr.
+ */
+void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
+{
+ if (image->hp_action == KEXEC_CRASH_HP_ADD_CPU ||
+ image->hp_action == KEXEC_CRASH_HP_REMOVE_CPU)
+ return;
+
+ update_crash_elfcorehdr(image, (struct memory_notify *)arg);
+}
+#endif /* CONFIG_CRASH_HOTPLUG */
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 3d907f8ee594..c0d0442fad9b 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -14,7 +14,6 @@
#include <linux/kernel.h>
#include <linux/kexec.h>
#include <linux/libfdt.h>
-#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/slab.h>
@@ -39,34 +38,6 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
return kexec_image_post_load_cleanup_default(image);
}
-#ifdef CONFIG_CRASH_DUMP
-unsigned int arch_get_system_nr_ranges(void)
-{
- unsigned int nr_ranges = 2 + crashk_cma_cnt; /* for exclusion of crashkernel region */
- phys_addr_t start, end;
- u64 i;
-
- for_each_mem_range(i, &start, &end)
- nr_ranges++;
-
- return nr_ranges;
-}
-
-int arch_crash_populate_cmem(struct crash_mem *cmem)
-{
- phys_addr_t start, end;
- u64 i;
-
- for_each_mem_range(i, &start, &end) {
- cmem->ranges[cmem->nr_ranges].start = start;
- cmem->ranges[cmem->nr_ranges].end = end - 1;
- cmem->nr_ranges++;
- }
-
- return 0;
-}
-#endif
-
/*
* Tries to add the initrd and DTB to the image. If it is not possible to find
* valid locations, this function will undo changes to the image and return non
@@ -89,8 +60,9 @@ int load_other_segments(struct kimage *image,
kbuf.buf_min = kernel_load_addr + kernel_size;
#ifdef CONFIG_CRASH_DUMP
+ unsigned long nr_ranges = 0;
if (image->type == KEXEC_TYPE_CRASH) {
- ret = crash_prepare_headers(true, &kbuf.buffer, &kbuf.bufsz, NULL);
+ ret = crash_prepare_headers(true, &kbuf.buffer, &kbuf.bufsz, &nr_ranges);
if (ret) {
pr_err("Preparing elf core header failed\n");
goto out_err;
@@ -100,10 +72,13 @@ int load_other_segments(struct kimage *image,
vfree(image->elf_headers);
image->elf_headers = kbuf.buffer;
- image->elf_headers_sz = kbuf.bufsz;
kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
- kbuf.memsz = kbuf.bufsz;
+ kbuf.memsz = kbuf.bufsz + crash_extra_elfcorehdr_size(nr_ranges);
+ image->elf_headers_sz = kbuf.memsz;
+#ifdef CONFIG_CRASH_HOTPLUG
+ image->elfcorehdr_index = image->nr_segments;
+#endif
kbuf.buf_align = SZ_64K; /* largest supported page size */
kbuf.buf_max = ULONG_MAX;
kbuf.top_down = true;
@@ -177,6 +152,9 @@ int load_other_segments(struct kimage *image,
return 0;
out_err:
+#ifdef CONFIG_CRASH_HOTPLUG
+ image->elfcorehdr_index = -1;
+#endif
while (image->nr_segments > orig_segments) {
kexec_free_segment_cma(image, image->nr_segments - 1);
image->nr_segments--;
--
2.34.1
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5 17/17] arm64: crash: Add crash hotplug support
2026-09-18 10:04 ` [PATCH v5 17/17] arm64: crash: Add crash hotplug support Jinjie Ruan
@ 2026-09-18 10:36 ` sashiko-bot
0 siblings, 0 replies; 36+ messages in thread
From: sashiko-bot @ 2026-09-18 10:36 UTC (permalink / raw)
To: tglx, ritesh.list, mark.rutland, chao.gao, kas, linuxppc-dev,
yeoreum.yun, x86, baoquan.he, hbathini, sourabhjain,
linux-kernel, loongarch, jbouron, dave.hansen, rafael, coxu,
akpm, gshan, vishal.l.verma, ruirui.yang, seanjc, bgwin,
Jinjie Ruan, chenhuacai, pasha.tatashin, kees, me, npiggin,
maddy, ruanjinjie, thuth, graf, palmer, chleroy, guodongtai,
zhangtianyang, eric.devolder, catalin.marinas, leitao,
driver-core, piliu, kernel, dakr, pratyush, sshegde, tangyouling,
adityag, rppt, mclapinski, takahiro.akashi, linux-arm-kernel,
will, ardb, gregkh, lizhengyu3, linux-mm, james.morse,
linux-fsdevel, mpe, mingo, bp, blum, robh, hpa, liukexin,
maqianga
Cc: kexec
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kexec: arch_crash_get_elfcorehdr_size() exports undersized buffer when MEMORY_HOTPLUG is disabled
--
commit fd293f9cfd1a12554d9352f4ad58fc9f85721fa3
Author: Jinjie Ruan <ruanjinjie@huawei.com>
arm64: crash: Add crash hotplug support
This commit introduces kernel mechanisms to update only the elfcorehdr
on memory hotplug events for arm64. It adds ARCH_SUPPORTS_CRASH_HOTPLUG
and implements arch-specific functions to handle memory hotplug, avoiding
full kdump image reloads from userspace.
Link: https://lore.kernel.org/all/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b5a51b0ef9440..96de2660b1cbb 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1720,6 +1720,9 @@ config ARCH_DEFAULT_CRASH_DUMP
> config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> def_bool CRASH_RESERVE
>
> +config ARCH_SUPPORTS_CRASH_HOTPLUG
> + def_bool y
> +
[Severity: High]
Does unconditionally enabling ARCH_SUPPORTS_CRASH_HOTPLUG here expose an
undersized buffer to userspace when CONFIG_MEMORY_HOTPLUG is disabled?
Since CONFIG_HOTPLUG_CPU natively selects CONFIG_CRASH_HOTPLUG on
architectures that support it, having this default to 'y' allows
CRASH_HOTPLUG to be active even without MEMORY_HOTPLUG. This leads to the
size calculation issue below.
[ ... ]
> diff --git a/arch/arm64/kernel/crash.c b/arch/arm64/kernel/crash.c
> new file mode 100644
> index 0000000000000..08dc9b952498e
> --- /dev/null
> +++ b/arch/arm64/kernel/crash.c
[ ... ]
> +unsigned int arch_crash_get_elfcorehdr_size(void)
> +{
> + unsigned long phdr_cnt;
> +
> + /* A program header for possible CPUs, vmcoreinfo and kernel_map */
> + phdr_cnt = 2 + num_possible_cpus();
> + if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
> + phdr_cnt += CONFIG_CRASH_MAX_MEMORY_RANGES;
> +
[Severity: High]
Is this calculation missing the static memory ranges when
CONFIG_MEMORY_HOTPLUG is disabled?
If compiled with CONFIG_HOTPLUG_CPU=y (which natively selects
CONFIG_CRASH_HOTPLUG) and CONFIG_MEMORY_HOTPLUG=n, phdr_cnt is computed as
exactly 2 + num_possible_cpus(). This does not account for the mandatory
memblock ranges from arch_get_system_nr_ranges().
Unlike x86 or powerpc which might survive this due to heavily padded
CONFIG_NR_CPUS_DEFAULT values, arm64's precise num_possible_cpus() leaves
zero headroom. As a result, the exported maximum elfcorehdr size is strictly
smaller than the required size to hold static memory ranges, and any attempt
to arm kdump (kexec -p) will fail because kexec-tools cannot load the crash
kernel into the undersized segment.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918100442.3841135-1-ruanjinjie@huawei.com?part=17
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support
2026-09-18 10:04 [PATCH v5 00/17] crash: Rework and add arm64 crash hotplug support Jinjie Ruan
` (16 preceding siblings ...)
2026-09-18 10:04 ` [PATCH v5 17/17] arm64: crash: Add crash hotplug support Jinjie Ruan
@ 2026-09-18 10:41 ` Breno Leitao
17 siblings, 0 replies; 36+ messages in thread
From: Breno Leitao @ 2026-09-18 10:41 UTC (permalink / raw)
To: Jinjie Ruan
Cc: catalin.marinas, will, mark.rutland, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, ritesh.list, sshegde, tglx, mingo, bp,
dave.hansen, hpa, gregkh, rafael, dakr, akpm, baoquan.he, rppt,
pasha.tatashin, pratyush, ruirui.yang, kees, thuth, gshan, ardb,
james.morse, yeoreum.yun, sourabhjain, robh, coxu, tangyouling,
liukexin, guodongtai, maqianga, zhangtianyang, blum, adityag,
chao.gao, kas, vishal.l.verma, seanjc, piliu, jbouron, me,
mclapinski, graf, bgwin, eric.devolder, hbathini,
takahiro.akashi, lizhengyu3, palmer, x86, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, driver-core, kexec,
linux-fsdevel, linux-mm
On Fri, Sep 18, 2026 at 06:04:25PM +0800, Jinjie Ruan wrote:
> When CPU or memory hotplug events occur, the elfcorehdr in the kdump
> image becomes stale, potentially leading to incomplete crash dumps.
Looking through the series, it seems to mix bug fixes with new
feature work. Would it make sense to split out the fixes so they
can land independently, and keep the new features as a separate
patchset?
I'm currently rolling out crashdump CMA across the Meta fleet, so
right now I care mostly about picking up isolated bug fixes. As it
stands, it's difficult to tell which patches are fixes and which
are features.
^ permalink raw reply [flat|nested] 36+ messages in thread