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 set implements crash hotplug support for arm64.
It also addresses and fixes several critical pre-existing code issues
and Sashiko AI review findings extracted from the previous patch set,
following Baoquan's suggestions.
The major improvements and fixes included in this series are:
- Fix powerpc memory leak, null-ptr-def and overlapping memory
range truncation bug.
- Fix several memory leaks for arm64.
- Simplify arm64 load_other_segments().
- Implement infrastructure for arm64 crash memory hotplug support.
This patch set is rebased on liveupdate/crashkernel-cma.
Link: https://lore.kernel.org/all/20260601094805.2928614-1-ruanjinjie@huawei.com/
Jinjie Ruan (8):
powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
powerpc/kexec_file: Fix null-ptr-def in extra size calculation
powerpc/kexec_file: Prevent kexec range truncation
kexec: Extract kexec_free_segment_cma() from kimage_free_cma()
arm64: kexec_file: Fix CMA page leaks in segment placement retry loops
arm64: kexec_file: Fix image->elf_headers memory leak during retry
loop
arm64: kexec_file: Simplify load_other_segments()
arm64: crash: Add crash hotplug support
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/kexec.h | 13 +++
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/crash.c | 148 +++++++++++++++++++++++++
arch/arm64/kernel/kexec_image.c | 1 +
arch/arm64/kernel/machine_kexec_file.c | 76 ++++++-------
arch/powerpc/kexec/crash.c | 2 +-
arch/powerpc/kexec/file_load_64.c | 2 +-
arch/powerpc/kexec/ranges.c | 12 +-
include/linux/kexec.h | 2 +
kernel/kexec_core.c | 25 +++--
11 files changed, 223 insertions(+), 63 deletions(-)
create mode 100644 arch/arm64/kernel/crash.c
--
2.34.1
Sashiko AI review pointed out the following issue.
The __merge_memory_ranges() function incorrectly handles overlapping
memory ranges when merging them. Although sort_memory_ranges() sorts all
ranges by their start address in ascending order beforehand, the merge
logic remains defective in two ways:
1. It compares the current range's start against the previous element (i-1)
instead of the running target index (idx)
2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'.
This logic flaw leads to critical memory truncation when a larger memory
range completely subsumes subsequent smaller ranges.
For example, consider a sorted input array with three ranges:
Range A (idx=0): [0x1000 - 0x9000]
Range B (i=1): [0x2000 - 0x5000] (completely inside Range A)
Range C (i=2): [0x6000 - 0x8000] (completely inside Range A)
1. When i=1 (Range B):
ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE.
The code executes: ranges[0].end = ranges[1].end, which erroneously
shrinks Range A's end from 0x9000 down to 0x5000.
2. When i=2 (Range C):
ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE.
The code falls into the else block, creating a broken new range.
As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000]
are completely lost from the kexec exclude lists, potentially allowing
the crash kernel to overwrite active memory, causing data corruption
or crashes.
Fix this by ensuring the start of the current range is compared against the
end of the active merged range (idx), and use max() to safely prevent the
outer boundary from being truncated.
Cc: Sourabh Jain <redacted>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: stable@vger.kernel.org
Fixes: 180adfc532a8 ("powerpc/kexec_file: Add helper functions for getting memory ranges")
Signed-off-by: Jinjie Ruan <redacted>
---
arch/powerpc/kexec/ranges.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
A static Sashiko AI review identified a potential NULL pointer
dereference in kexec_extra_fdt_size_ppc64().
On platforms without any reserved memory regions,
get_reserved_memory_ranges() can return 0 while leaving 'rmem'
unallocated as NULL. Passing it directly leads to a kernel panic when
evaluating 'rmem->nr_ranges'.
Add a NULL check for 'rmem' to prevent this crash.
Cc: Sourabh Jain <redacted>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: stable@vger.kernel.org
Fixes: 0d3ff067331e ("powerpc/kexec_file: fix extra size calculation for kexec FDT")
Signed-off-by: Jinjie Ruan <redacted>
---
arch/powerpc/kexec/file_load_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -664,7 +664,7 @@ unsigned int kexec_extra_fdt_size_ppc64(struct kimage *image, struct crash_mem *extra_size+=(cpu_nodes-boot_cpu_node_count)*cpu_node_size();/* Consider extra space for reserved memory ranges if any */-if(rmem->nr_ranges>0)+if(rmem&&rmem->nr_ranges>0)extra_size+=sizeof(structfdt_reserve_entry)*rmem->nr_ranges;returnextra_size+kdump_extra_fdt_size_ppc64(image,cpu_nodes);
The generic kimage_free_cma() relies on `image->nr_segments` to iterate
and free allocated CMA pages. However, during architecture-specific
segment placement retry loops (e.g., arm64's image_load()), a mid-way
failure will truncate `image->nr_segments` back to its initial value.
This truncation permanently hides any CMA pages allocated outside the
new boundary from global cleanup, causing silent background memory leaks.
To allow architecture-specific loaders to execute fine-grained memory
reclamation before truncation occurs, extract the single-pass CMA release
logic into a dedicated and exported helper:
void kexec_free_segment_cma(struct kimage *image, unsigned long idx);
Refactor the main kimage_free_cma() to invoke this helper sequentially
to maintain backward compatibility while expanding single-slot flexibility.
Signed-off-by: Jinjie Ruan <redacted>
---
include/linux/kexec.h | 2 ++
kernel/kexec_core.c | 25 ++++++++++++++-----------
2 files changed, 16 insertions(+), 11 deletions(-)
In get_crash_memory_ranges(), if crash_exclude_mem_range() failed
after realloc_mem_ranges() has successfully allocated the cmem
memory, it just returns an error but leaves cmem pointing to
the allocated memory, nor is it freed in the caller
update_crash_elfcorehdr(), which cause a memory leak, goto out
to free the cmem.
Cc: Sourabh Jain <redacted>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support")
Reviewed-by: Sourabh Jain <redacted>
Signed-off-by: Jinjie Ruan <redacted>
---
arch/powerpc/kexec/crash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Sashiko AI code review pointed out a potential memory leak of
image->elf_headers when load_other_segments() fails on error paths.
When load_other_segments() fails during the arm64 kexec_file file-load
path, execution jumps to the out_err label. While this path restores
`image->nr_segments`, it returns an error back to the caller without
freeing the allocated `image->elf_headers` vmalloc buffer.
Consequently, the retry loop in image_load() will allocate new ELF
headers on the next iteration and overwrite `image->elf_headers`,
permanently leaking the memory blocks allocated in previous iterations.
Fix this by explicitly freeing the stale `image->elf_headers` buffer
once the new headers buffer is allocated.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Thomas Huth <redacted>
Cc: Breno Leitao <leitao@debian.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yeoreum Yun <redacted>
Cc: Coiby Xu <redacted>
Cc: Baoquan He <redacted>
Cc: Kees Cook <kees@kernel.org>
Cc: Benjamin Gwin <redacted>
Cc: stable@vger.kernel.org
Fixes: 108aa503657e ("arm64: kexec_file: try more regions if loading segments fails")
Signed-off-by: Jinjie Ruan <redacted>
---
arch/arm64/kernel/machine_kexec_file.c | 4 ++++
1 file changed, 4 insertions(+)
Use `kbuf` fields directly in crash_prepare_headers() so the local
variables "headers" and "headers_sz" can be removed.
Additionally, assign the allocated buffer to `image->elf_headers` before
calling kexec_add_buffer(). If kexec_add_buffer() fails, the explicit
vfree() in the error path can be eliminated, as the allocated elf header
memory will be automatically freed via `image->elf_headers` in
arch_kimage_file_post_load_cleanup().
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Baoquan He <redacted>
Cc: Breno Leitao <leitao@debian.org>
Signed-off-by: Jinjie Ruan <redacted>
---
arch/arm64/kernel/machine_kexec_file.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
Sashiko AI code review pointed out, during kexec image placement retry
loops in image_load(), the loader attempts to find a suitable memory
hole for the kernel and its associated segments (initrd, dtb, etc.).
When a placement attempt fails midway, it restores `image->nr_segments` to
its initial state to purge failed segments.
However, this truncation causes a memory leak. Any CMA pages allocated
via kexec_add_buffer() during the failed attempt are tracked in
the `image->segment_cma` array. Because the subsequent cleanup
kimage_free_cma() cleanup only iterates up to the truncated `nr_segments`
boundary, these allocated CMA pages outside the new boundary permanently
leaked.
Fix this by using kexec_free_segment_cma() to explicitly release 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 <redacted>
Cc: Kees Cook <kees@kernel.org>
Cc: "Rob Herring (Arm)" <robh@kernel.org>
Cc: Baoquan He <redacted>
Cc: Coiby Xu <redacted>
Cc: Alexander Graf <graf@amazon.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: stable@vger.kernel.org
Fixes: 07d24902977e4 ("kexec: enable CMA based contiguous allocation")
Signed-off-by: Jinjie Ruan <redacted>
---
arch/arm64/kernel/kexec_image.c | 1 +
arch/arm64/kernel/machine_kexec_file.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
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").
Tested with QEMU [2] virtual machine using:
-M virt,acpi=on,highmem=on
-smp cpus=1,maxcpus=3
-bios /usr/share/edk2/aarch64/QEMU_EFI.fd
-m 2G,slots=64,maxmem=16G
Only kexec_file_load path has been tested; kexec_load is expected to
work via KEXEC_CRASH_HOTPLUG_SUPPORT flag but not yet verified.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Baoquan He <redacted>
Cc: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Breno Leitao <leitao@debian.org>
Cc: Kees Cook <kees@kernel.org>
[1]: https://lore.kernel.org/all/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
[2]: https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v2
Signed-off-by: Jinjie Ruan <redacted>
---
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/kexec.h | 13 +++
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/crash.c | 148 +++++++++++++++++++++++++
arch/arm64/kernel/machine_kexec_file.c | 53 ++++-----
5 files changed, 187 insertions(+), 32 deletions(-)
create mode 100644 arch/arm64/kernel/crash.c
@@ -0,0 +1,148 @@+// SPDX-License-Identifier: GPL-2.0-only+/*+*Architecturespecificfunctionsforkexecbasedcrashdumps.+*/++#define pr_fmt(fmt) "crash hp: " fmt++#include<linux/kexec.h>+#include<linux/elf.h>+#include<linux/memblock.h>+#include<linux/vmalloc.h>+#include<linux/cacheflush.h>+#include<linux/crash_core.h>++#include<asm/kexec.h>++#if defined(CONFIG_KEXEC_FILE) || defined(CONFIG_CRASH_HOTPLUG)+unsignedintarch_get_system_nr_ranges(void)+{+unsignedintnr_ranges=2+crashk_cma_cnt;/* for exclusion of crashkernel region */+phys_addr_tstart,end;+u64i;++for_each_mem_range(i,&start,&end)+nr_ranges++;++returnnr_ranges;+}++intarch_crash_populate_cmem(structcrash_mem*cmem)+{+phys_addr_tstart,end;+u64i;++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++;+}++return0;+}+#endif++#ifdef CONFIG_CRASH_HOTPLUG+intarch_crash_hotplug_support(structkimage*image,unsignedlongkexec_flags)+{+#ifdef CONFIG_KEXEC_FILE+if(image->file_mode)+return1;+#endif+/*+*Forkexec_loadsyscall,crashhotplugsupportrequires+*KEXEC_CRASH_HOTPLUG_SUPPORTflagtobepassedbyuserspace.+*/+returnkexec_flags&KEXEC_CRASH_HOTPLUG_SUPPORT;+}++unsignedintarch_crash_get_elfcorehdr_size(void)+{+unsignedintphdr_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;++returnpnum_hdr_sz(phdr_cnt);+}++/**+*update_crash_elfcorehdr()-Recreatetheelfcorehdrandreplaceitwithold+*elfcorehdrinthekexecsegmentarray.+*@image:theactivestructkimage+*/+staticvoidupdate_crash_elfcorehdr(structkimage*image)+{+void*elfbuf=NULL,*old_elfcorehdr;+unsignedlongmem,memsz;+unsignedlongelfsz=0;++/*+*CreatethenewelfcorehdrreflectingthechangestoCPUand/or+*memoryresources.+*/+if(crash_prepare_headers(true,&elfbuf,&elfsz,NULL)){+pr_err("unable to create new elfcorehdr");+gotoout;+}++/*+*Obtainaddressandsizeoftheelfcorehdrsegment,and+*checkitagainstthenewelfcorehdrbuffer.+*/+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);+gotoout;+}++/*+*Copynewelfcorehdrovertheoldelfcorehdratdestination.+*/+old_elfcorehdr=(void*)__va(mem);+if(!old_elfcorehdr){+pr_err("mapping elfcorehdr segment failed\n");+gotoout;+}++/*+*Temporarilyinvalidatethecrashimagewhilethe+*elfcorehdrisupdated.+*/+xchg(&kexec_crash_image,NULL);+memcpy((void*)old_elfcorehdr,elfbuf,elfsz);+dcache_clean_inval_poc((unsignedlong)old_elfcorehdr,+(unsignedlong)old_elfcorehdr+elfsz);+xchg(&kexec_crash_image,image);+pr_debug("updated elfcorehdr\n");++out:+vfree(elfbuf);+}++/**+*arch_crash_handle_hotplug_event()-Handlehotplugelfcorehdrchanges+*@image:apointertokexec_crash_image+*@arg:structmemory_notifyhandlerformemoryhotplugcaseand+*NULLforCPUhotplugcase.+*+*Updatethekdumpimagebasedonthetypeofhotplugevent:+*-CPUaddandremove:Noactionisneeded.+*-Memoryadd/remove:Updatetheelfcorehdrtoreflectthecurrentmemorylayout.+*+*Preparethenewelfcorehdrandreplacetheexistingelfcorehdr.+*/+voidarch_crash_handle_hotplug_event(structkimage*image,void*arg)+{+if((image->file_mode||image->elfcorehdr_updated)&&+((image->hp_action==KEXEC_CRASH_HP_ADD_CPU)||+(image->hp_action==KEXEC_CRASH_HP_REMOVE_CPU)))+return;++update_crash_elfcorehdr(image);+}+#endif /* CONFIG_CRASH_HOTPLUG */
@@ -39,34 +38,6 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)returnkexec_image_post_load_cleanup_default(image);}-#ifdef CONFIG_CRASH_DUMP-unsignedintarch_get_system_nr_ranges(void)-{-unsignedintnr_ranges=2+crashk_cma_cnt;/* for exclusion of crashkernel region */-phys_addr_tstart,end;-u64i;--for_each_mem_range(i,&start,&end)-nr_ranges++;--returnnr_ranges;-}--intarch_crash_populate_cmem(structcrash_mem*cmem)-{-phys_addr_tstart,end;-u64i;--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++;-}--return0;-}-#endif-/**TriestoaddtheinitrdandDTBtotheimage.Ifitisnotpossibletofind*validlocations,thisfunctionwillundochangestotheimageandreturnnon
From: Mike Rapoport <rppt@kernel.org> Date: 2026-07-26 07:10:48
Hi Jinjie,
On Thu, Jul 23, 2026 at 09:12:34PM +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.
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 set implements crash hotplug support for arm64.
It also addresses and fixes several critical pre-existing code issues
and Sashiko AI review findings extracted from the previous patch set,
following Baoquan's suggestions.
The major improvements and fixes included in this series are:
- Fix powerpc memory leak, null-ptr-def and overlapping memory
range truncation bug.
- Fix several memory leaks for arm64.
- Simplify arm64 load_other_segments().
- Implement infrastructure for arm64 crash memory hotplug support.
This patch set is rebased on liveupdate/crashkernel-cma.
Link: https://lore.kernel.org/all/20260601094805.2928614-1-ruanjinjie@huawei.com/
Jinjie Ruan (8):
powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
powerpc/kexec_file: Fix null-ptr-def in extra size calculation
powerpc/kexec_file: Prevent kexec range truncation
It's weird to see powerpc fixes in a series that adds a feature for arm64.
Judging by the subjects, they are completely unrelated to to crash support
for hotplug and should be sent as a separate set.
Hi Jinjie,
On Thu, Jul 23, 2026 at 09:12:34PM +0800, Jinjie Ruan wrote:
quoted
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 set implements crash hotplug support for arm64.
It also addresses and fixes several critical pre-existing code issues
and Sashiko AI review findings extracted from the previous patch set,
following Baoquan's suggestions.
The major improvements and fixes included in this series are:
- Fix powerpc memory leak, null-ptr-def and overlapping memory
range truncation bug.
- Fix several memory leaks for arm64.
- Simplify arm64 load_other_segments().
- Implement infrastructure for arm64 crash memory hotplug support.
This patch set is rebased on liveupdate/crashkernel-cma.
Link: https://lore.kernel.org/all/20260601094805.2928614-1-ruanjinjie@huawei.com/
Jinjie Ruan (8):
powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
powerpc/kexec_file: Fix null-ptr-def in extra size calculation
powerpc/kexec_file: Prevent kexec range truncation
It's weird to see powerpc fixes in a series that adds a feature for arm64.
Judging by the subjects, they are completely unrelated to to crash support
for hotplug and should be sent as a separate set.
Hi Mike,
You are right, I'll rebase and post v2 shortly, and send the powerpc
fixes as a standalone series.