* Re: [PATCH] powerpc/vdso: Drop -DCC_USING_PATCHABLE_FUNCTION_ENTRY from 32-bit flags with clang
From: Madhavan Srinivasan @ 2026-05-11 2:28 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Hari Bathini, Nathan Chancellor
Cc: linuxppc-dev, llvm, patches
In-Reply-To: <20260311-ppc-vdso-drop-cc-using-pfe-define-clang-v1-1-66c790e22650@kernel.org>
On Wed, 11 Mar 2026 17:39:56 -0700, Nathan Chancellor wrote:
> After commit 73cdf24e81e4 ("powerpc64: make clang cross-build
> friendly"), building 64-bit little endian + CONFIG_COMPAT=y with clang
> results in many warnings along the lines of:
>
> $ cat arch/powerpc/configs/compat.config
> CONFIG_COMPAT=y
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/vdso: Drop -DCC_USING_PATCHABLE_FUNCTION_ENTRY from 32-bit flags with clang
https://git.kernel.org/powerpc/c/60c71369ee356d11ad845ddeb28ceb70ec6cd70e
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: Fix interrupt mask in cpm1_gpiochip_add16()
From: Madhavan Srinivasan @ 2026-05-11 2:28 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP)
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <bb0b6d6c4543238c38d5d29a776d0674a8c0c180.1776752750.git.chleroy@kernel.org>
On Tue, 21 Apr 2026 08:26:08 +0200, Christophe Leroy (CS GROUP) wrote:
> Allthough fsl,cpm1-gpio-irq-mask always contains a 16 bits value,
> it is a standard u32 OF property as documented in
> Documentation/devicetree/bindings/soc/fsl/cpm_qe/gpio.txt
>
> The driver erroneously uses of_property_read_u16() leading to a
> mask which is always 0.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/8xx: Fix interrupt mask in cpm1_gpiochip_add16()
https://git.kernel.org/powerpc/c/da107152c43915211e1fc0319b9526f4241abca2
cheers
^ permalink raw reply
* Re: [PATCH v3 0/9] pseries/papr-hvpipe: Fix deadlock, races and misc cleanups
From: Madhavan Srinivasan @ 2026-05-11 2:28 UTC (permalink / raw)
To: linuxppc-dev, Haren Myneni, Ritesh Harjani (IBM)
Cc: Christophe Leroy, Venkat Rao Bagalkote, Nicholas Piggin,
linux-kernel
In-Reply-To: <cover.1777606826.git.ritesh.list@gmail.com>
On Fri, 01 May 2026 09:41:39 +0530, Ritesh Harjani (IBM) wrote:
> While going over papr-hvpipe code, there were a few fixes which were identified.
> This patch series is an attempt to fix those along with some misc cleanups.
> Me and Haren are trying to get these patches verified on a real HW. The tests
> are not straight forward and we are waiting for the results.
> Will update on the test results once we hear back from the internal test team.
>
> v2->v3:
> ======
> 1. Rearranged the patches in such a way that it is easier to backport the fixes
> if required.
> 2. Clubbed patch-8 and patch-10 (of v2) since they both were changing the same function.
> 3. Handled ret>=0 case in copy_to_user patch, when the user itself may request
> for 0 effective bytes (after the HDR_LEN).
>
> [...]
Applied to powerpc/fixes.
[1/9] pseries/papr-hvpipe: Fix race with interrupt handler
https://git.kernel.org/powerpc/c/7a4f0846ee6cc8cf44ae0046ed42e3259d1dd45b
[2/9] pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace
https://git.kernel.org/powerpc/c/cefeed44296261173a806bef988b26bc565da4be
[3/9] pseries/papr-hvpipe: Fix null ptr deref in papr_hvpipe_dev_create_handle()
https://git.kernel.org/powerpc/c/1b9f7aafa44f5ce852c00509104d10fd9eb0f402
[4/9] pseries/papr-hvpipe: Fix & simplify error handling in papr_hvpipe_init()
https://git.kernel.org/powerpc/c/713e468cdbc2277db6ce949c32c1acbd83501733
[5/9] pseries/papr-hvpipe: Fix the usage of copy_to_user()
https://git.kernel.org/powerpc/c/d48654bd8b1a75f662e224d257db54de475120dc
[6/9] pseries/papr-hvpipe: Simplify spin unlock usage in papr_hvpipe_handle_release()
https://git.kernel.org/powerpc/c/2eeac577480848801b35885b3a8201aa35f46236
[7/9] pseries/papr-hvpipe: Kill task_struct pointer from struct hvpipe_source_info
https://git.kernel.org/powerpc/c/4e2d83c80495a9327141e8636f25dde13155f14f
[8/9] pseries/papr-hvpipe: Refactor and simplify hvpipe_rtas_recv_msg()
https://git.kernel.org/powerpc/c/fe53d2ae82c06aa2d6402624af01e8f8ddfcd5b3
[9/9] pseries/papr-hvpipe: Fix style and checkpatch issues in enable_hvpipe_IRQ()
https://git.kernel.org/powerpc/c/629d1a901de57490d29a495273df11e64993ec04
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Update check for PERF_SAMPLE_DATA_SRC marked events
From: Madhavan Srinivasan @ 2026-05-11 2:28 UTC (permalink / raw)
To: linuxppc-dev, Shivani Nittor; +Cc: atrajeev, hbathini, Tejas.Manhas1
In-Reply-To: <20260421150628.96500-1-shivani@linux.ibm.com>
On Tue, 21 Apr 2026 20:36:28 +0530, Shivani Nittor wrote:
> The core-book3s PMU sampling code validates the SIER TYPE field
> when PERF_SAMPLE_DATA_SRC is requested. The SIER TYPE field
> indicates the instruction type and is only valid for
> random sampling (marked events). To handle cases observed where
> SIER TYPE could be zero even for marked events,validation was
> added to drop such samples and increment event->lost_samples.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/perf: Update check for PERF_SAMPLE_DATA_SRC marked events
https://git.kernel.org/powerpc/c/131717e656b379addb95af2dcb2d90c723bae24b
cheers
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o
From: Madhavan Srinivasan @ 2026-05-11 2:28 UTC (permalink / raw)
To: linuxppc-dev, Sourabh Jain
Cc: Venkat Rao Bagalkote, Aditya Gupta, Daniel Axtens, Hari Bathini,
Michael Ellerman, Shivang Upadhyay, stable, Ritesh Harjani (IBM),
Mahesh Salgaonkar, Aboorva Devarajan
In-Reply-To: <20260407124349.1698552-1-sourabhjain@linux.ibm.com>
On Tue, 07 Apr 2026 18:13:44 +0530, Sourabh Jain wrote:
> KASAN instrumentation is intended to be disabled for the kexec core
> code, but the existing Makefile entry misses the object suffix. As a
> result, the flag is not applied correctly to core_$(BITS).o.
>
> So when KASAN is enabled, kexec_copy_flush and copy_segments in
> kexec/core_64.c are instrumented, which can result in accesses to
> shadow memory via normal address translation paths. Since these run
> with the MMU disabled, such accesses may trigger page faults
> (bad_page_fault) that cannot be handled in the kdump path, ultimately
> causing a hang and preventing the kdump kernel from booting. The same
> is true for kexec as well, since the same functions are used there.
>
> [...]
Applied to powerpc/fixes.
[1/2] powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o
https://git.kernel.org/powerpc/c/b3a97f9484080c6e71db9e803e3cc1bb372a9bc7
[2/2] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec
https://git.kernel.org/powerpc/c/38e989d504fc52900a3786b7144fb53cd67e0389
cheers
^ permalink raw reply
* Re: [PATCH RESEND 1/2] powerpc/ps3: Drop redundant result assignment
From: Madhavan Srinivasan @ 2026-05-11 2:28 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Geoff Levand, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, linuxppc-dev, linux-kernel, llvm,
Krzysztof Kozlowski
In-Reply-To: <20260317130823.240279-3-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 17 Mar 2026 14:08:24 +0100, Krzysztof Kozlowski wrote:
> Return value of ps3_start_probe_thread() is not used, so code can be
> simplified to fix W=1 clang warnings:
>
> arch/powerpc/platforms/ps3/device-init.c:953:6: error: variable 'result' set but not used [-Werror,-Wunused-but-set-variable]
>
>
Applied to powerpc/fixes.
[1/2] powerpc/ps3: Drop redundant result assignment
https://git.kernel.org/powerpc/c/8333e4916040e529bd5b56b82d573aba51e88a14
[2/2] powerpc/pasemi: Drop redundant res assignment
https://git.kernel.org/powerpc/c/f583bd5f64d40e083dde5bb22846c4d93e59d471
cheers
^ permalink raw reply
* Re: [PATCH] arch/powerpc: Drop CONFIG_FIRMWARE_EDID from defconfig files
From: Madhavan Srinivasan @ 2026-05-11 2:28 UTC (permalink / raw)
To: mpe, npiggin, chleroy, arnd, Thomas Zimmermann; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20260401083023.214426-1-tzimmermann@suse.de>
On Wed, 01 Apr 2026 10:30:03 +0200, Thomas Zimmermann wrote:
> CONFIG_FIRMWARE_EDID=y depends on X86 or EFI_GENERIC_STUB. Neither is
> true here, so drop the lines from the defconfig files.
>
>
Applied to powerpc/fixes.
[1/1] arch/powerpc: Drop CONFIG_FIRMWARE_EDID from defconfig files
https://git.kernel.org/powerpc/c/4052b932041614675fa2dbf48f725557c23ebf05
cheers
^ permalink raw reply
* [PATCH v13 01/15] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
riscv should have excluded the "crashk_low_res" reserved ranges from
the crash kernel memory to prevent them from being exported through
/proc/vmcore, and the exclusion would need an extra crash_mem range.
Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned
in [2]. And the second kernel can be started normally.
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB)
Cc: Guo Ren <guoren@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
[1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
[2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/
Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
Reviewed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 54e2d9552e93..3f7766057cac 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
unsigned int nr_ranges;
int ret;
- nr_ranges = 1; /* For exclusion of crashkernel region */
+ nr_ranges = 2; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
@@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
/* Exclude crashkernel region */
ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (!ret)
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
+ if (ret)
+ goto out;
+
+ if (crashk_low_res.end) {
+ ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ if (ret)
+ goto out;
+ }
+
+ ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
out:
kfree(cmem);
--
2.34.1
^ permalink raw reply related
* [PATCH v13 02/15] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
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 <sourabhjain@linux.ibm.com>
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 <sourabhjain@linux.ibm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/kexec/crash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index e6539f213b3d..a520f851c3a6 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -502,7 +502,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
ret = get_crash_memory_ranges(&cmem);
if (ret) {
pr_err("Failed to get crash mem range\n");
- return;
+ goto out;
}
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v13 03/15] x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. get_nr_ram_ranges_callback() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. prepare_elf64_ram_headers_callback() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Since x86 supports crash hotplug, any data inconsistency caused by
a race during the initial load will be corrected by the subsequent
hotplug update. However, we must prevent a buffer overflow if the
number of memory regions increases between the two passes.
Add a boundary checking in prepare_elf64_ram_headers_callback() to ensure
that the number of populated ranges does not exceed
the allocated maximum.
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 8d5f894a3108 ("x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/x86/kernel/crash.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index cd796818d94d..fa6a1feb1bf1 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -226,6 +226,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
struct crash_mem *cmem = arg;
+ if (cmem->nr_ranges >= cmem->max_nr_ranges)
+ return -ENOMEM;
+
cmem->ranges[cmem->nr_ranges].start = res->start;
cmem->ranges[cmem->nr_ranges].end = res->end;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 00/15] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
The crash memory allocation, and the exclude of crashk_res, crashk_low_res
and crashk_cma memory are almost identical across different architectures,
This patch set handle them in crash core in a general way, which eliminate
a lot of duplication code.
And add support for crashkernel CMA reservation for arm64 and riscv.
Rebased on v7.1-rc1.
Basic second kernel boot test were performed on QEMU platforms for x86,
ARM64 and RISC-V architectures with the following parameters:
"cma=256M crashkernel=4G crashkernel=64M,cma"
For first kernel, there will be such log:
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xe8000000 - 0xf0000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x000000023e600000 - 0x000000033e600000 (4096 MB)
[ 0.000000] crashkernel CMA reserved: 64 MB in 1 ranges
# dmesg | grep cma
[ 0.000000] cma: Reserved 256 MiB at 0x00000000f0000000
[ 0.000000] cma: Reserved 64 MiB at 0x0000000100000000
For second kernel, there will be such log:
[ 0.000000] OF: fdt: Looking for usable-memory-range property...
[ 0.000000] OF: fdt: cap_mem_regions[0]: base=0x000000023e600000, size=0x0000000100000000
[ 0.000000] OF: fdt: cap_mem_regions[1]: base=0x00000000e8000000, size=0x0000000008000000
[ 0.000000] OF: fdt: cap_mem_regions[2]: base=0x0000000100000000, size=0x0000000004000000
Changes in v13:
- Rebased on v7.1-rc1.
- Update the commit message.
- Add Reviewed-by.
- Link to v12: https://lore.kernel.org/all/20260402072701.628293-1-ruanjinjie@huawei.com/
Changes in v12:
- Remove the unused "nr_mem_ranges" for x86.
- Add "Fix crashk_low_res not exclude bug" test log.
- Provide a separate patch for each architecture for using
crash_prepare_headers(), which will make the review more convenient.
- Add Reviewed-by and Tested-by.
- Link to v11: https://lore.kernel.org/all/20260328074013.3589544-1-ruanjinjie@huawei.com/
Changes in v11:
- Avoid silently drop crash memory if the crash kernel is built without
CONFIG_CMA.
- Remove unnecessary "cmem->nr_ranges = 0" for arch_crash_populate_cmem()
as we use kvzalloc().
- Provide a separate patch for each architecture to fix the existing
buffer overflow issue.
- Add Acked-bys for arm64.
Changes in v10:
- Fix crashk_low_res not excluded bug in the existing
RISC-V code.
- Fix an existing memory leak issue in the existing PowerPC code.
- Fix the ordering issue of adding CMA ranges to
"linux,usable-memory-range".
- Fix an existing concurrency issue. A Concurrent memory hotplug may occur
between reading memblock and attempting to fill cmem during kexec_load()
for almost all existing architectures.
- Link to v9: https://lore.kernel.org/all/20260323072745.2481719-1-ruanjinjie@huawei.com/
Changes in v9:
- Collect Reviewed-by and Acked-by, and prepare for Sashiko AI review.
- Link to v8: https://lore.kernel.org/all/20260302035315.3892241-1-ruanjinjie@huawei.com/
Changes in v8:
- Fix the build issues reported by kernel test robot and Sourabh.
- Link to v7: https://lore.kernel.org/all/20260226130437.1867658-1-ruanjinjie@huawei.com/
Changes in v7:
- Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec
for arm64 and riscv.
- Add Acked-by.
- Link to v6: https://lore.kernel.org/all/20260224085342.387996-1-ruanjinjie@huawei.com/
Changes in v6:
- Update the crash core exclude code as Mike suggested.
- Rebased on v7.0-rc1.
- Add acked-by.
- Link to v5: https://lore.kernel.org/all/20260212101001.343158-1-ruanjinjie@huawei.com/
Jinjie Ruan (14):
riscv: kexec_file: Fix crashk_low_res not exclude bug
powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
arm64: kexec_file: Fix potential buffer overflow in
prepare_elf_headers()
riscv: kexec_file: Fix potential buffer overflow in
prepare_elf_headers()
LoongArch: kexec: Fix potential buffer overflow in
prepare_elf_headers()
crash: Add crash_prepare_headers() to exclude crash kernel memory
arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
x86/kexec: Use crash_prepare_headers() helper to simplify code
riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
crash: Use crash_exclude_core_ranges() on powerpc
arm64: kexec: Add support for crashkernel CMA reservation
riscv: kexec: Add support for crashkernel CMA reservation
Sourabh Jain (1):
powerpc/crash: sort crash memory ranges before preparing elfcorehdr
.../admin-guide/kernel-parameters.txt | 16 +--
arch/arm64/kernel/machine_kexec_file.c | 43 +++-----
arch/arm64/mm/init.c | 5 +-
arch/loongarch/kernel/machine_kexec_file.c | 43 +++-----
arch/powerpc/include/asm/kexec_ranges.h | 1 -
arch/powerpc/kexec/crash.c | 7 +-
arch/powerpc/kexec/ranges.c | 101 +-----------------
arch/riscv/kernel/machine_kexec_file.c | 42 +++-----
arch/riscv/mm/init.c | 5 +-
arch/x86/kernel/crash.c | 92 +++-------------
drivers/of/fdt.c | 9 +-
drivers/of/kexec.c | 9 ++
include/linux/crash_core.h | 9 ++
include/linux/crash_reserve.h | 4 +-
kernel/crash_core.c | 98 ++++++++++++++++-
15 files changed, 202 insertions(+), 282 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v13 04/15] arm64: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can
lead to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. The first for_each_mem_range() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. The 2st for_each_mem_range() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Add the explicit bounds checking to prevent out-of-bounds access.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Breno Leitao <leitao@debian.org>
Cc: stable@vger.kernel.org
Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support")
Closes: https://sashiko.dev/#/patchset/20260323072745.2481719-1-ruanjinjie%40huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/machine_kexec_file.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index e31fabed378a..a67e7b1abbab 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -59,6 +59,11 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
cmem->max_nr_ranges = nr_ranges;
cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
+ if (cmem->nr_ranges >= cmem->max_nr_ranges) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 05/15] riscv: kexec_file: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. get_nr_ram_ranges_callback() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. prepare_elf64_ram_headers_callback() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
While this works today because RISC-V server hardware with hotplug
support is still rare and most deployments use fixed memory configurations
(e.g., QEMU virt machine), it is technically fragile. So add bounds
checking in prepare_elf64_ram_headers_callback() to prevent
out-of-bounds (OOB) access.
No functional change for current RISC-V deployments, but makes
the code robust against future hotplug-capable platforms.
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: songshuaishuai@tinylab.org
Cc: bjorn@rivosinc.com
Cc: leitao@debian.org
Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic")
Reviewed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 3f7766057cac..773a1cba8ba0 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -48,6 +48,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
struct crash_mem *cmem = arg;
+ if (cmem->nr_ranges >= cmem->max_nr_ranges)
+ return -ENOMEM;
+
cmem->ranges[cmem->nr_ranges].start = res->start;
cmem->ranges[cmem->nr_ranges].end = res->end;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 06/15] LoongArch: kexec: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. The first for_each_mem_range() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. The 2st for_each_mem_range() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Just add bounds checking to prevent out-of-bounds access.
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: Huacai Chen <chenhuacai@loongson.cn>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: stable@vger.kernel.org
Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/loongarch/kernel/machine_kexec_file.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 5584b798ba46..167392c1da33 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -75,6 +75,11 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
cmem->max_nr_ranges = nr_ranges;
cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
+ if (cmem->nr_ranges >= cmem->max_nr_ranges) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 07/15] powerpc/crash: sort crash memory ranges before preparing elfcorehdr
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
From: Sourabh Jain <sourabhjain@linux.ibm.com>
During a memory hot-remove event, the elfcorehdr is rebuilt to exclude
the removed memory. While updating the crash memory ranges for this
operation, the crash memory ranges array can become unsorted. This
happens because remove_mem_range() may split a memory range into two
parts and append the higher-address part as a separate range at the end
of the array.
So far, no issues have been observed due to the unsorted crash memory
ranges. However, this could lead to problems once crash memory range
removal is handled by generic code, as introduced in the upcoming
patches in this series.
Currently, powerpc uses a platform-specific function,
remove_mem_range(), to exclude hot-removed memory from the crash memory
ranges. This function performs the same task as the generic
crash_exclude_mem_range() in crash_core.c. The generic helper also
ensures that the crash memory ranges remain sorted. So remove the
redundant powerpc-specific implementation and instead call
crash_exclude_mem_range_guarded() (which internally calls
crash_exclude_mem_range()) to exclude the hot-removed memory ranges.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Baoquan he <bhe@redhat.com>
Cc: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/include/asm/kexec_ranges.h | 4 +-
arch/powerpc/kexec/crash.c | 5 +-
arch/powerpc/kexec/ranges.c | 87 +------------------------
3 files changed, 7 insertions(+), 89 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include/asm/kexec_ranges.h
index 14055896cbcb..ad95e3792d10 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++ b/arch/powerpc/include/asm/kexec_ranges.h
@@ -7,7 +7,9 @@
void sort_memory_ranges(struct crash_mem *mrngs, bool merge);
struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges);
int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
-int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
+int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
+ unsigned long long mstart,
+ unsigned long long mend);
int get_exclude_memory_ranges(struct crash_mem **mem_ranges);
int get_reserved_memory_ranges(struct crash_mem **mem_ranges);
int get_crash_memory_ranges(struct crash_mem **mem_ranges);
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index a520f851c3a6..d634db67becc 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -493,7 +493,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
struct crash_mem *cmem = NULL;
struct kexec_segment *ksegment;
void *ptr, *mem, *elfbuf = NULL;
- unsigned long elfsz, memsz, base_addr, size;
+ unsigned long elfsz, memsz, base_addr, size, end;
ksegment = &image->segment[image->elfcorehdr_index];
mem = (void *) ksegment->mem;
@@ -512,7 +512,8 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
if (image->hp_action == KEXEC_CRASH_HP_REMOVE_MEMORY) {
base_addr = PFN_PHYS(mn->start_pfn);
size = mn->nr_pages * PAGE_SIZE;
- ret = remove_mem_range(&cmem, base_addr, size);
+ end = base_addr + size - 1;
+ ret = crash_exclude_mem_range_guarded(&cmem, base_addr, end);
if (ret) {
pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
goto out;
diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
index 867135560e5c..6c58bcc3e130 100644
--- a/arch/powerpc/kexec/ranges.c
+++ b/arch/powerpc/kexec/ranges.c
@@ -553,7 +553,7 @@ int get_usable_memory_ranges(struct crash_mem **mem_ranges)
#endif /* CONFIG_KEXEC_FILE */
#ifdef CONFIG_CRASH_DUMP
-static int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
+int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
unsigned long long mstart,
unsigned long long mend)
{
@@ -641,89 +641,4 @@ int get_crash_memory_ranges(struct crash_mem **mem_ranges)
pr_err("Failed to setup crash memory ranges\n");
return ret;
}
-
-/**
- * remove_mem_range - Removes the given memory range from the range list.
- * @mem_ranges: Range list to remove the memory range to.
- * @base: Base address of the range to remove.
- * @size: Size of the memory range to remove.
- *
- * (Re)allocates memory, if needed.
- *
- * Returns 0 on success, negative errno on error.
- */
-int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size)
-{
- u64 end;
- int ret = 0;
- unsigned int i;
- u64 mstart, mend;
- struct crash_mem *mem_rngs = *mem_ranges;
-
- if (!size)
- return 0;
-
- /*
- * Memory range are stored as start and end address, use
- * the same format to do remove operation.
- */
- end = base + size - 1;
-
- for (i = 0; i < mem_rngs->nr_ranges; i++) {
- mstart = mem_rngs->ranges[i].start;
- mend = mem_rngs->ranges[i].end;
-
- /*
- * Memory range to remove is not part of this range entry
- * in the memory range list
- */
- if (!(base >= mstart && end <= mend))
- continue;
-
- /*
- * Memory range to remove is equivalent to this entry in the
- * memory range list. Remove the range entry from the list.
- */
- if (base == mstart && end == mend) {
- for (; i < mem_rngs->nr_ranges - 1; i++) {
- mem_rngs->ranges[i].start = mem_rngs->ranges[i+1].start;
- mem_rngs->ranges[i].end = mem_rngs->ranges[i+1].end;
- }
- mem_rngs->nr_ranges--;
- goto out;
- }
- /*
- * Start address of the memory range to remove and the
- * current memory range entry in the list is same. Just
- * move the start address of the current memory range
- * entry in the list to end + 1.
- */
- else if (base == mstart) {
- mem_rngs->ranges[i].start = end + 1;
- goto out;
- }
- /*
- * End address of the memory range to remove and the
- * current memory range entry in the list is same.
- * Just move the end address of the current memory
- * range entry in the list to base - 1.
- */
- else if (end == mend) {
- mem_rngs->ranges[i].end = base - 1;
- goto out;
- }
- /*
- * Memory range to remove is not at the edge of current
- * memory range entry. Split the current memory entry into
- * two half.
- */
- else {
- size = mem_rngs->ranges[i].end - end + 1;
- mem_rngs->ranges[i].end = base - 1;
- ret = add_mem_range(mem_ranges, end + 1, size);
- }
- }
-out:
- return ret;
-}
#endif /* CONFIG_CRASH_DUMP */
--
2.34.1
^ permalink raw reply related
* [PATCH v13 08/15] crash: Add crash_prepare_headers() to exclude crash kernel memory
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
The crash memory alloc, and the exclude of crashk_res, crashk_low_res
and crashk_cma memory are almost identical across different architectures,
handling them in the crash core would eliminate a lot of duplication, so
add crash_prepare_headers() helper to handle them in the common code.
To achieve the above goal, three architecture-specific functions are
introduced:
- arch_get_system_nr_ranges(). Pre-counts the max number of memory ranges.
- arch_crash_populate_cmem(). Collects the memory ranges and fills them
into cmem.
- arch_crash_exclude_ranges(). Architecture's additional crash memory
ranges exclusion, defaulting to empty.
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
include/linux/crash_core.h | 5 +++
kernel/crash_core.c | 91 ++++++++++++++++++++++++++++++++++++--
2 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index c1dee3f971a9..583ffcc703d4 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -59,6 +59,8 @@ extern int crash_exclude_mem_range(struct crash_mem *mem,
unsigned long long mend);
extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
void **addr, unsigned long *sz);
+extern int crash_prepare_headers(int need_kernel_map, void **addr,
+ unsigned long *sz, unsigned long *nr_mem_ranges);
struct kimage;
struct kexec_segment;
@@ -76,6 +78,9 @@ int kexec_should_crash(struct task_struct *p);
int kexec_crash_loaded(void);
void crash_save_cpu(struct pt_regs *regs, int cpu);
extern int kimage_crash_copy_vmcoreinfo(struct kimage *image);
+extern unsigned int arch_get_system_nr_ranges(void);
+extern int arch_crash_populate_cmem(struct crash_mem *cmem);
+extern int arch_crash_exclude_ranges(struct crash_mem *cmem);
#else /* !CONFIG_CRASH_DUMP*/
struct pt_regs;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 4f21fc3b108b..d28be3890efb 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -16,6 +16,7 @@
#include <linux/mm.h>
#include <linux/cpuhotplug.h>
#include <linux/memblock.h>
+#include <linux/memory_hotplug.h>
#include <linux/kmemleak.h>
#include <linux/crash_core.h>
#include <linux/reboot.h>
@@ -168,9 +169,6 @@ static inline resource_size_t crash_resource_size(const struct resource *res)
return !res->end ? 0 : resource_size(res);
}
-
-
-
int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
void **addr, unsigned long *sz)
{
@@ -272,6 +270,93 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
return 0;
}
+static struct crash_mem *alloc_cmem(unsigned int nr_ranges)
+{
+ struct crash_mem *cmem;
+
+ cmem = kvzalloc_flex(*cmem, ranges, nr_ranges);
+ if (!cmem)
+ return NULL;
+
+ cmem->max_nr_ranges = nr_ranges;
+ return cmem;
+}
+
+unsigned int __weak arch_get_system_nr_ranges(void) { return 0; }
+int __weak arch_crash_populate_cmem(struct crash_mem *cmem) { return -1; }
+int __weak arch_crash_exclude_ranges(struct crash_mem *cmem) { return 0; }
+
+static int crash_exclude_core_ranges(struct crash_mem *cmem)
+{
+ int ret, i;
+
+ /* Exclude crashkernel region */
+ ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
+ if (ret)
+ return ret;
+
+ if (crashk_low_res.end) {
+ ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ if (ret)
+ return ret;
+ }
+
+ for (i = 0; i < crashk_cma_cnt; ++i) {
+ ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
+ crashk_cma_ranges[i].end);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
+ unsigned long *nr_mem_ranges)
+{
+ unsigned int max_nr_ranges;
+ struct crash_mem *cmem;
+ int ret;
+
+ get_online_mems();
+ max_nr_ranges = arch_get_system_nr_ranges();
+ if (!max_nr_ranges) {
+ put_online_mems();
+ return -ENOMEM;
+ }
+
+ cmem = alloc_cmem(max_nr_ranges);
+ if (!cmem) {
+ put_online_mems();
+ return -ENOMEM;
+ }
+
+ ret = arch_crash_populate_cmem(cmem);
+ if (ret) {
+ put_online_mems();
+ goto out;
+ }
+
+ put_online_mems();
+ ret = crash_exclude_core_ranges(cmem);
+ if (ret)
+ goto out;
+
+ ret = arch_crash_exclude_ranges(cmem);
+ if (ret)
+ goto out;
+
+ /* 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;
+}
+
/**
* crash_exclude_mem_range - exclude a mem range for existing ranges
* @mem: mem->range contains an array of ranges sorted in ascending order
--
2.34.1
^ permalink raw reply related
* [PATCH v13 09/15] arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash
kernel memory in the crash core, which reduce code duplication.
Only the following two architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Use for_each_mem_range() to traverse
and pre-count the max number of memory ranges.
- arch_crash_populate_cmem(). Use for_each_mem_range to traverse
and collect the memory ranges and fills them into cmem.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/arm64/kernel/machine_kexec_file.c | 46 ++++++++------------------
1 file changed, 14 insertions(+), 32 deletions(-)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index a67e7b1abbab..8d72038f206d 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -40,51 +40,33 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
}
#ifdef CONFIG_CRASH_DUMP
-static int prepare_elf_headers(void **addr, unsigned long *sz)
+unsigned int arch_get_system_nr_ranges(void)
{
- struct crash_mem *cmem;
- unsigned int nr_ranges;
- int ret;
- u64 i;
+ unsigned int nr_ranges = 2; /* for exclusion of crashkernel region */
phys_addr_t start, end;
+ u64 i;
- nr_ranges = 2; /* for exclusion of crashkernel region */
for_each_mem_range(i, &start, &end)
nr_ranges++;
- cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
- if (!cmem)
- return -ENOMEM;
+ return nr_ranges;
+}
+
+int arch_crash_populate_cmem(struct crash_mem *cmem)
+{
+ phys_addr_t start, end;
+ u64 i;
- cmem->max_nr_ranges = nr_ranges;
- cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
- if (cmem->nr_ranges >= cmem->max_nr_ranges) {
- ret = -ENOMEM;
- goto out;
- }
+ if (cmem->nr_ranges >= cmem->max_nr_ranges)
+ return -ENOMEM;
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
}
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret)
- goto out;
-
- if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
- if (ret)
- goto out;
- }
-
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
-
-out:
- kfree(cmem);
- return ret;
+ return 0;
}
#endif
@@ -114,7 +96,7 @@ int load_other_segments(struct kimage *image,
void *headers;
unsigned long headers_sz;
if (image->type == KEXEC_TYPE_CRASH) {
- ret = prepare_elf_headers(&headers, &headers_sz);
+ ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
if (ret) {
pr_err("Preparing elf core header failed\n");
goto out_err;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 10/15] x86/kexec: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
memory in the crash core, which reduce code duplication.
Only the following three architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
to pre-count the max number of memory ranges.
- arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
to collect the memory ranges and fills them into cmem.
- arch_crash_exclude_ranges(). Exclude the low 1M for x86.
By the way, remove the unused "nr_mem_ranges" in
arch_crash_handle_hotplug_event().
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: Andrew Morton <akpm@linux-foundation.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/x86/kernel/crash.c | 89 +++++------------------------------------
1 file changed, 11 insertions(+), 78 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index fa6a1feb1bf1..8cf6e115196e 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -153,16 +153,8 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
return 0;
}
-/* Gather all the required information to prepare elf headers for ram regions */
-static struct crash_mem *fill_up_crash_elf_data(void)
+unsigned int arch_get_system_nr_ranges(void)
{
- unsigned int nr_ranges = 0;
- struct crash_mem *cmem;
-
- walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
- if (!nr_ranges)
- return NULL;
-
/*
* Exclusion of crash region, crashk_low_res and/or crashk_cma_ranges
* may cause range splits. So add extra slots here.
@@ -177,49 +169,16 @@ static struct crash_mem *fill_up_crash_elf_data(void)
* But in order to lest the low 1M could be changed in the future,
* (e.g. [start, 1M]), add a extra slot.
*/
- nr_ranges += 3 + crashk_cma_cnt;
- cmem = vzalloc(struct_size(cmem, ranges, nr_ranges));
- if (!cmem)
- return NULL;
-
- cmem->max_nr_ranges = nr_ranges;
+ unsigned int nr_ranges = 3 + crashk_cma_cnt;
- return cmem;
+ walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
+ return nr_ranges;
}
-/*
- * Look for any unwanted ranges between mstart, mend and remove them. This
- * might lead to split and split ranges are put in cmem->ranges[] array
- */
-static int elf_header_exclude_ranges(struct crash_mem *cmem)
+int arch_crash_exclude_ranges(struct crash_mem *cmem)
{
- int ret = 0;
- int i;
-
/* Exclude the low 1M because it is always reserved */
- ret = crash_exclude_mem_range(cmem, 0, SZ_1M - 1);
- if (ret)
- return ret;
-
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret)
- return ret;
-
- if (crashk_low_res.end)
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
- crashk_low_res.end);
- if (ret)
- return ret;
-
- for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
- if (ret)
- return ret;
- }
-
- return 0;
+ return crash_exclude_mem_range(cmem, 0, SZ_1M - 1);
}
static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
@@ -236,35 +195,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
return 0;
}
-/* Prepare elf headers. Return addr and size */
-static int prepare_elf_headers(void **addr, unsigned long *sz,
- unsigned long *nr_mem_ranges)
+int arch_crash_populate_cmem(struct crash_mem *cmem)
{
- struct crash_mem *cmem;
- int ret;
-
- cmem = fill_up_crash_elf_data();
- if (!cmem)
- return -ENOMEM;
-
- ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
- if (ret)
- goto out;
-
- /* Exclude unwanted mem ranges */
- ret = elf_header_exclude_ranges(cmem);
- if (ret)
- goto out;
-
- /* Return the computed number of memory ranges, for hotplug usage */
- *nr_mem_ranges = cmem->nr_ranges;
-
- /* By default prepare 64bit headers */
- ret = crash_prepare_elf64_headers(cmem, IS_ENABLED(CONFIG_X86_64), addr, sz);
-
-out:
- vfree(cmem);
- return ret;
+ return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
}
#endif
@@ -422,7 +355,8 @@ int crash_load_segments(struct kimage *image)
.buf_max = ULONG_MAX, .top_down = false };
/* Prepare elf headers and add a segment */
- ret = prepare_elf_headers(&kbuf.buffer, &kbuf.bufsz, &pnum);
+ ret = crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &kbuf.buffer,
+ &kbuf.bufsz, &pnum);
if (ret)
return ret;
@@ -515,7 +449,6 @@ 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 nr_mem_ranges;
unsigned long mem, memsz;
unsigned long elfsz = 0;
@@ -533,7 +466,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
* Create the new elfcorehdr reflecting the changes to CPU and/or
* memory resources.
*/
- if (prepare_elf_headers(&elfbuf, &elfsz, &nr_mem_ranges)) {
+ if (crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NULL)) {
pr_err("unable to create new elfcorehdr");
goto out;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v13 11/15] riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
memory in the crash core, which reduce code duplication.
Only the following two architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
to pre-counts the max number of memory ranges.
- arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
to collects the memory ranges and fills them into cmem.
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Guo Ren <guoren@kernel.org>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 47 +++++++-------------------
1 file changed, 12 insertions(+), 35 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 773a1cba8ba0..bea818f75dd6 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -44,6 +44,15 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
return 0;
}
+unsigned int arch_get_system_nr_ranges(void)
+{
+ unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
+
+ walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
+
+ return nr_ranges;
+}
+
static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
struct crash_mem *cmem = arg;
@@ -58,41 +67,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
return 0;
}
-static int prepare_elf_headers(void **addr, unsigned long *sz)
+int arch_crash_populate_cmem(struct crash_mem *cmem)
{
- struct crash_mem *cmem;
- unsigned int nr_ranges;
- int ret;
-
- nr_ranges = 2; /* For exclusion of crashkernel region */
- walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
-
- cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
- if (!cmem)
- return -ENOMEM;
-
- cmem->max_nr_ranges = nr_ranges;
- cmem->nr_ranges = 0;
- ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
- if (ret)
- goto out;
-
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret)
- goto out;
-
- if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
- if (ret)
- goto out;
- }
-
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
-
-out:
- kfree(cmem);
- return ret;
+ return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
}
static char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
@@ -284,7 +261,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
if (image->type == KEXEC_TYPE_CRASH) {
void *headers;
unsigned long headers_sz;
- ret = prepare_elf_headers(&headers, &headers_sz);
+ ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
if (ret) {
pr_err("Preparing elf core header failed\n");
goto out;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 12/15] LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
Use the newly introduced crash_prepare_headers() function to replace
the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
memory in the crash core, which reduce code duplication.
Only the following two architecture functions need to be implemented:
- arch_get_system_nr_ranges(). Use for_each_mem_range to traverse
and pre-count the max number of memory ranges.
- arch_crash_populate_cmem(). Use for_each_mem_range to traverse
and collect the memory ranges and fills them into cmem.
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: WANG Xuerui <kernel@xen0n.name>
Cc: Youling Tang <tangyouling@kylinos.cn>
Cc: Baoquan He <bhe@redhat.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/loongarch/kernel/machine_kexec_file.c | 46 +++++++---------------
1 file changed, 14 insertions(+), 32 deletions(-)
diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
index 167392c1da33..3d0386ee18ef 100644
--- a/arch/loongarch/kernel/machine_kexec_file.c
+++ b/arch/loongarch/kernel/machine_kexec_file.c
@@ -56,51 +56,33 @@ static void cmdline_add_initrd(struct kimage *image, unsigned long *cmdline_tmpl
}
#ifdef CONFIG_CRASH_DUMP
-
-static int prepare_elf_headers(void **addr, unsigned long *sz)
+unsigned int arch_get_system_nr_ranges(void)
{
- int ret, nr_ranges;
- uint64_t i;
+ int nr_ranges = 2; /* for exclusion of crashkernel region */
phys_addr_t start, end;
- struct crash_mem *cmem;
+ uint64_t i;
- nr_ranges = 2; /* for exclusion of crashkernel region */
for_each_mem_range(i, &start, &end)
nr_ranges++;
- cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
- if (!cmem)
- return -ENOMEM;
+ return nr_ranges;
+}
+
+int arch_crash_populate_cmem(struct crash_mem *cmem)
+{
+ phys_addr_t start, end;
+ uint64_t i;
- cmem->max_nr_ranges = nr_ranges;
- cmem->nr_ranges = 0;
for_each_mem_range(i, &start, &end) {
- if (cmem->nr_ranges >= cmem->max_nr_ranges) {
- ret = -ENOMEM;
- goto out;
- }
+ if (cmem->nr_ranges >= cmem->max_nr_ranges)
+ return -ENOMEM;
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
}
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (ret < 0)
- goto out;
-
- if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
- if (ret < 0)
- goto out;
- }
-
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
-
-out:
- kfree(cmem);
- return ret;
+ return 0;
}
/*
@@ -168,7 +150,7 @@ int load_other_segments(struct kimage *image,
void *headers;
unsigned long headers_sz;
- ret = prepare_elf_headers(&headers, &headers_sz);
+ ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
if (ret < 0) {
pr_err("Preparing elf core header failed\n");
goto out_err;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 13/15] crash: Use crash_exclude_core_ranges() on powerpc
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
The crash memory exclude of crashk_res and crashk_cma memory on powerpc
are almost identical to the generic crash_exclude_core_ranges().
By introducing the architecture-specific arch_crash_exclude_mem_range()
function with a default implementation of crash_exclude_mem_range(),
and using crash_exclude_mem_range_guarded as powerpc's separate
implementation, the generic crash_exclude_core_ranges() helper function
can be reused.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shivang Upadhyay <shivangu@linux.ibm.com>
Acked-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/include/asm/kexec_ranges.h | 3 ---
arch/powerpc/kexec/crash.c | 2 +-
arch/powerpc/kexec/ranges.c | 16 ++++------------
include/linux/crash_core.h | 4 ++++
kernel/crash_core.c | 19 +++++++++++++------
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec_ranges.h b/arch/powerpc/include/asm/kexec_ranges.h
index ad95e3792d10..8489e844b447 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++ b/arch/powerpc/include/asm/kexec_ranges.h
@@ -7,9 +7,6 @@
void sort_memory_ranges(struct crash_mem *mrngs, bool merge);
struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges);
int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
-int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
- unsigned long long mstart,
- unsigned long long mend);
int get_exclude_memory_ranges(struct crash_mem **mem_ranges);
int get_reserved_memory_ranges(struct crash_mem **mem_ranges);
int get_crash_memory_ranges(struct crash_mem **mem_ranges);
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index d634db67becc..775895f31037 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -513,7 +513,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
base_addr = PFN_PHYS(mn->start_pfn);
size = mn->nr_pages * PAGE_SIZE;
end = base_addr + size - 1;
- ret = crash_exclude_mem_range_guarded(&cmem, base_addr, end);
+ ret = arch_crash_exclude_mem_range(&cmem, base_addr, end);
if (ret) {
pr_err("Failed to remove hot-unplugged memory from crash memory ranges\n");
goto out;
diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
index 6c58bcc3e130..e5fea23b191b 100644
--- a/arch/powerpc/kexec/ranges.c
+++ b/arch/powerpc/kexec/ranges.c
@@ -553,9 +553,9 @@ int get_usable_memory_ranges(struct crash_mem **mem_ranges)
#endif /* CONFIG_KEXEC_FILE */
#ifdef CONFIG_CRASH_DUMP
-int crash_exclude_mem_range_guarded(struct crash_mem **mem_ranges,
- unsigned long long mstart,
- unsigned long long mend)
+int arch_crash_exclude_mem_range(struct crash_mem **mem_ranges,
+ unsigned long long mstart,
+ unsigned long long mend)
{
struct crash_mem *tmem = *mem_ranges;
@@ -604,18 +604,10 @@ int get_crash_memory_ranges(struct crash_mem **mem_ranges)
sort_memory_ranges(*mem_ranges, true);
}
- /* Exclude crashkernel region */
- ret = crash_exclude_mem_range_guarded(mem_ranges, crashk_res.start, crashk_res.end);
+ ret = crash_exclude_core_ranges(mem_ranges);
if (ret)
goto out;
- for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range_guarded(mem_ranges, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
- if (ret)
- goto out;
- }
-
/*
* FIXME: For now, stay in parity with kexec-tools but if RTAS/OPAL
* regions are exported to save their context at the time of
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 583ffcc703d4..bc087124cd78 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -61,6 +61,7 @@ extern int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_ma
void **addr, unsigned long *sz);
extern int crash_prepare_headers(int need_kernel_map, void **addr,
unsigned long *sz, unsigned long *nr_mem_ranges);
+extern int crash_exclude_core_ranges(struct crash_mem **cmem);
struct kimage;
struct kexec_segment;
@@ -81,6 +82,9 @@ extern int kimage_crash_copy_vmcoreinfo(struct kimage *image);
extern unsigned int arch_get_system_nr_ranges(void);
extern int arch_crash_populate_cmem(struct crash_mem *cmem);
extern int arch_crash_exclude_ranges(struct crash_mem *cmem);
+extern int arch_crash_exclude_mem_range(struct crash_mem **mem,
+ unsigned long long mstart,
+ unsigned long long mend);
#else /* !CONFIG_CRASH_DUMP*/
struct pt_regs;
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index d28be3890efb..c42eeabcbdac 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -286,24 +286,31 @@ unsigned int __weak arch_get_system_nr_ranges(void) { return 0; }
int __weak arch_crash_populate_cmem(struct crash_mem *cmem) { return -1; }
int __weak arch_crash_exclude_ranges(struct crash_mem *cmem) { return 0; }
-static int crash_exclude_core_ranges(struct crash_mem *cmem)
+int __weak arch_crash_exclude_mem_range(struct crash_mem **mem,
+ unsigned long long mstart,
+ unsigned long long mend)
+{
+ return crash_exclude_mem_range(*mem, mstart, mend);
+}
+
+int crash_exclude_core_ranges(struct crash_mem **cmem)
{
int ret, i;
/* Exclude crashkernel region */
- ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
if (ret)
return ret;
if (crashk_low_res.end) {
- ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
if (ret)
return ret;
}
for (i = 0; i < crashk_cma_cnt; ++i) {
- ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
- crashk_cma_ranges[i].end);
+ ret = arch_crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start,
+ crashk_cma_ranges[i].end);
if (ret)
return ret;
}
@@ -338,7 +345,7 @@ int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
}
put_online_mems();
- ret = crash_exclude_core_ranges(cmem);
+ ret = crash_exclude_core_ranges(&cmem);
if (ret)
goto out;
--
2.34.1
^ permalink raw reply related
* [PATCH v13 14/15] arm64: kexec: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the
crashkernel= command line option") and commit ab475510e042 ("kdump:
implement reserve_crashkernel_cma") added CMA support for kdump
crashkernel reservation.
Crash kernel memory reservation wastes production resources if too
large, risks kdump failure if too small, and faces allocation difficulties
on fragmented systems due to contiguous block constraints. The new
CMA-based crashkernel reservation scheme splits the "large fixed
reservation" into a "small fixed region + large CMA dynamic region": the
CMA memory is available to userspace during normal operation to avoid
waste, and is reclaimed for kdump upon crash—saving memory while
improving reliability.
So extend crashkernel CMA reservation support to arm64. The following
changes are made to enable CMA reservation:
- Parse and obtain the CMA reservation size along with other crashkernel
parameters.
- Call reserve_crashkernel_cma() to allocate the CMA region for kdump.
- Include the CMA-reserved ranges for kdump kernel to use.
- Exclude the CMA-reserved ranges from the crash kernel memory to
prevent them from being exported through /proc/vmcore, which is already
done in the crash core.
Update kernel-parameters.txt to document CMA support for crashkernel on
arm64 architecture.
Tested-by: Breno Leitao <leitao@debian.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
v7:
- Correct the inclusion of CMA-reserved ranges for kdump
kernel in of/kexec.
v3:
- Add Acked-by.
v2:
- Free cmem in prepare_elf_headers()
- Add the mtivation.
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/arm64/kernel/machine_kexec_file.c | 2 +-
arch/arm64/mm/init.c | 5 +++--
drivers/of/fdt.c | 9 +++++----
drivers/of/kexec.c | 9 +++++++++
include/linux/crash_reserve.h | 4 +++-
6 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4d0f545fb3ec..52742fab49a9 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1119,7 +1119,7 @@ Kernel parameters
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
crashkernel=size[KMG],cma
- [KNL, X86, ppc] Reserve additional crash kernel memory from
+ [KNL, X86, ARM64, PPC] Reserve additional crash kernel memory from
CMA. This reservation is usable by the first system's
userspace memory and kernel movable allocations (memory
balloon, zswap). Pages allocated from this memory range
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index 8d72038f206d..0590ff9eeab4 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -42,7 +42,7 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
#ifdef CONFIG_CRASH_DUMP
unsigned int arch_get_system_nr_ranges(void)
{
- unsigned int nr_ranges = 2; /* for exclusion of crashkernel region */
+ unsigned int nr_ranges = 2 + crashk_cma_cnt; /* for exclusion of crashkernel region */
phys_addr_t start, end;
u64 i;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 97987f850a33..227f58522dad 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -96,8 +96,8 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit;
static void __init arch_reserve_crashkernel(void)
{
+ unsigned long long crash_base, crash_size, cma_size = 0;
unsigned long long low_size = 0;
- unsigned long long crash_base, crash_size;
bool high = false;
int ret;
@@ -106,11 +106,12 @@ static void __init arch_reserve_crashkernel(void)
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&crash_size, &crash_base,
- &low_size, NULL, &high);
+ &low_size, &cma_size, &high);
if (ret)
return;
reserve_crashkernel_generic(crash_size, crash_base, low_size, high);
+ reserve_crashkernel_cma(cma_size);
}
static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 82f7327c59ea..0470acbd1fcf 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,11 +880,12 @@ static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
/*
* The main usage of linux,usable-memory-range is for crash dump kernel.
* Originally, the number of usable-memory regions is one. Now there may
- * be two regions, low region and high region.
- * To make compatibility with existing user-space and older kdump, the low
- * region is always the last range of linux,usable-memory-range if exist.
+ * be 2 + CRASHK_CMA_RANGES_MAX regions, low region, high region and cma
+ * regions. To make compatibility with existing user-space and older kdump,
+ * the high and low region are always the first two ranges of
+ * linux,usable-memory-range if exist.
*/
-#define MAX_USABLE_RANGES 2
+#define MAX_USABLE_RANGES (2 + CRASHK_CMA_RANGES_MAX)
/**
* early_init_dt_check_for_usable_mem_range - Decode usable memory range
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index b6837e299e7f..029903b986cb 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -458,6 +458,15 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
if (ret)
goto out;
}
+
+ for (int i = 0; i < crashk_cma_cnt; i++) {
+ ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
+ "linux,usable-memory-range",
+ crashk_cma_ranges[i].start,
+ crashk_cma_ranges[i].end - crashk_cma_ranges[i].start + 1);
+ if (ret)
+ goto out;
+ }
#endif
}
diff --git a/include/linux/crash_reserve.h b/include/linux/crash_reserve.h
index f0dc03d94ca2..30864d90d7f5 100644
--- a/include/linux/crash_reserve.h
+++ b/include/linux/crash_reserve.h
@@ -14,9 +14,11 @@
extern struct resource crashk_res;
extern struct resource crashk_low_res;
extern struct range crashk_cma_ranges[];
+
+#define CRASHK_CMA_RANGES_MAX 4
#if defined(CONFIG_CMA) && defined(CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION)
#define CRASHKERNEL_CMA
-#define CRASHKERNEL_CMA_RANGES_MAX 4
+#define CRASHKERNEL_CMA_RANGES_MAX (CRASHK_CMA_RANGES_MAX)
extern int crashk_cma_cnt;
#else
#define crashk_cma_cnt 0
--
2.34.1
^ permalink raw reply related
* [PATCH v13 15/15] riscv: kexec: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-05-11 3:04 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, pmladek,
dapeng1.mi, kees, elver, kuba, ebiggers, lirongqing, paulmck,
ruanjinjie, sourabhjain, coxu, leitao, jbohac, ryan.roberts,
osandov, cfsworks, tangyouling, ritesh.list, adityag, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu,
wangruikang, namcao, chao.gao, seanjc, fuqiang.wang, ardb,
chenjiahao16, hbathini, takahiro.akashi, james.morse, lizhengyu3,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260511030454.1730881-1-ruanjinjie@huawei.com>
Commit 35c18f2933c5 ("Add a new optional ",cma" suffix to the
crashkernel= command line option") and commit ab475510e042 ("kdump:
implement reserve_crashkernel_cma") added CMA support for kdump
crashkernel reservation. This allows the kernel to dynamically allocate
contiguous memory for crash dumping when needed, rather than permanently
reserving a fixed region at boot time.
So extend crashkernel CMA reservation support to riscv. The following
changes are made to enable CMA reservation:
- Parse and obtain the CMA reservation size along with other crashkernel
parameters.
- Call reserve_crashkernel_cma() to allocate the CMA region for kdump.
- Include the CMA-reserved ranges for kdump kernel to use, which was
already done in of_kexec_alloc_and_setup_fdt().
- Exclude the CMA-reserved ranges from the crash kernel memory to
prevent them from being exported through /proc/vmcore, which was
already done in the crash core.
Update kernel-parameters.txt to document CMA support for crashkernel on
riscv architecture.
Cc: Paul Walmsley <pjw@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Paul Walmsley <pjw@kernel.org> # arch/riscv
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++--------
arch/riscv/kernel/machine_kexec_file.c | 2 +-
arch/riscv/mm/init.c | 5 +++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 52742fab49a9..3ff3ddd516cf 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1119,14 +1119,14 @@ Kernel parameters
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
crashkernel=size[KMG],cma
- [KNL, X86, ARM64, PPC] Reserve additional crash kernel memory from
- CMA. This reservation is usable by the first system's
- userspace memory and kernel movable allocations (memory
- balloon, zswap). Pages allocated from this memory range
- will not be included in the vmcore so this should not
- be used if dumping of userspace memory is intended and
- it has to be expected that some movable kernel pages
- may be missing from the dump.
+ [KNL, X86, ARM64, RISCV, PPC] Reserve additional crash
+ kernel memory from CMA. This reservation is usable by
+ the first system's userspace memory and kernel movable
+ allocations (memory balloon, zswap). Pages allocated
+ from this memory range will not be included in the vmcore
+ so this should not be used if dumping of userspace memory
+ is intended and it has to be expected that some movable
+ kernel pages may be missing from the dump.
A standard crashkernel reservation, as described above,
is still needed to hold the crash kernel and initrd.
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index bea818f75dd6..c79cd86d5713 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -46,7 +46,7 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
unsigned int arch_get_system_nr_ranges(void)
{
- unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
+ unsigned int nr_ranges = 2 + crashk_cma_cnt; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index decd7df40fa4..c848454b8349 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -1295,7 +1295,7 @@ static inline void setup_vm_final(void)
*/
static void __init arch_reserve_crashkernel(void)
{
- unsigned long long low_size = 0;
+ unsigned long long low_size = 0, cma_size = 0;
unsigned long long crash_base, crash_size;
bool high = false;
int ret;
@@ -1305,11 +1305,12 @@ static void __init arch_reserve_crashkernel(void)
ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
&crash_size, &crash_base,
- &low_size, NULL, &high);
+ &low_size, &cma_size, &high);
if (ret)
return;
reserve_crashkernel_generic(crash_size, crash_base, low_size, high);
+ reserve_crashkernel_cma(cma_size);
}
void __init paging_init(void)
--
2.34.1
^ permalink raw reply related
* Re: crypto/ahash.c:1073:1: warning: the frame size of 1040 bytes is larger than 1024 bytes
From: Geert Uytterhoeven @ 2026-05-11 6:42 UTC (permalink / raw)
To: kernel test robot
Cc: Herbert Xu, oe-kbuild-all, linux-kernel, linux-mips, linuxppc-dev,
wireguard
In-Reply-To: <202605100125.l4JVHppO-lkp@intel.com>
On Sat, 9 May 2026 at 19:07, kernel test robot <lkp@intel.com> wrote:
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: ec89572766744e844df24c27d31c97b4c00f4e07
> commit: 9d9b193ed73a65ec47cf1fd39925b09da8216461 crypto: hash - Increase HASH_MAX_DESCSIZE for hmac(sha3-224-s390)
> date: 9 months ago
> config: mips-eyeq5_defconfig (https://download.01.org/0day-ci/archive/20260510/202605100125.l4JVHppO-lkp@intel.com/config)
> compiler: mips64-linux-gcc (GCC) 15.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260510/202605100125.l4JVHppO-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Fixes: 9d9b193ed73a ("crypto: hash - Increase HASH_MAX_DESCSIZE for hmac(sha3-224-s390)")
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202605100125.l4JVHppO-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> crypto/ahash.c: In function 'crypto_hash_digest':
> >> crypto/ahash.c:1073:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 1073 | }
> | ^
This is one of the few defconfigs that still use CONFIG_FRAME_WARN=1024.
The default value for 32-bit systems was lifted from 1024 to 1280 in
commit 32115734c0ed8b46 ("Increase the default 32-bit build frame size
warning limit to 1280 bytes") in v6.18, so perhaps the downgrade to
1024 should be dropped from the following defconfigs:
$ git grep CONFIG_FRAME_WARN=1024
arch/mips/configs/eyeq5_defconfig:CONFIG_FRAME_WARN=1024
arch/mips/configs/eyeq6_defconfig:CONFIG_FRAME_WARN=1024
arch/mips/configs/eyeq6lplus_defconfig:CONFIG_FRAME_WARN=1024
arch/mips/configs/lemote2f_defconfig:CONFIG_FRAME_WARN=1024
arch/mips/configs/loongson2k_defconfig:CONFIG_FRAME_WARN=1024
arch/powerpc/configs/fsl-emb-nonhw.config:CONFIG_FRAME_WARN=1024
tools/testing/selftests/wireguard/qemu/arch/arm.config:CONFIG_FRAME_WARN=1024
tools/testing/selftests/wireguard/qemu/arch/armeb.config:CONFIG_FRAME_WARN=1024
tools/testing/selftests/wireguard/qemu/arch/i686.config:CONFIG_FRAME_WARN=1024
tools/testing/selftests/wireguard/qemu/arch/m68k.config:CONFIG_FRAME_WARN=1024
tools/testing/selftests/wireguard/qemu/arch/mips.config:CONFIG_FRAME_WARN=1024
tools/testing/selftests/wireguard/qemu/arch/mipsel.config:CONFIG_FRAME_WARN=1024
tools/testing/selftests/wireguard/qemu/arch/powerpc.config:CONFIG_FRAME_WARN=1024
I am not sure about the wireguard selftests: they might use the lower
value deliberately for testing?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: powernv_rng_read: Oops: Kernel access of bad area, sig: 11 [#1]
From: Paul Menzel @ 2026-05-11 7:00 UTC (permalink / raw)
To: Madhavan Srinivasan, Olivia Mackall, Herbert Xu, Michael Ellerman
Cc: linux-crypto, linuxppc-dev, LKML, Jason A. Donenfeld
In-Reply-To: <0c06bc14-9459-44d5-9e28-b0b78c0fbe36@linux.ibm.com>
[Cc: +Jason]
Dear Madhavan,
Am 07.05.26 um 04:40 schrieb Madhavan Srinivasan:
>
> On 5/6/26 7:31 PM, Paul Menzel wrote:
>> After a long while, on the 8335-GCA POWER8 (raw) 0x4d0200
>> opal:skiboot-5.4.8-5787ad3 PowerNV, I built Linux from Linus’ master
>> branch and rebooted via kexec.
>>
>> ```
>> [ 0.000000] Linux version 7.1.0-rc2+ (pmenzel@flughafenberlinbrandenburgwillybrandt.molgen.mpg.de) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Wed May 6 08:50:58 CEST 2026
>> […]
>> [ 17.901992] Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
>> [ 17.902011] BUG: Kernel NULL pointer dereference on read at 0x00000000
>> [ 17.902018] Faulting instruction address: 0xc0000000000e7138
>> [ 17.902027] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 17.902034] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>> [ 17.902045] Modules linked in: powernv_rng(+) bnx2x ofpart ibmpowernv bfq mdio cmdlinepart powernv_flash ipmi_powernv ipmi_devintf mtd ipmi_msghandler at24(+) vmx_crypto opal_prd sch_fq_codel nfsd parport_pc ppdev auth_rpcgss nfs_acl lp lockd grace parport sunrpc autofs4 btrfs xor libblake2b raid6_pq ast drm_shmem_helper drm_client_lib i2c_algo_bit drm_kms_helper drm ahci drm_panel_orientation_quirks libahci
>> [ 17.902185] CPU: 147 UID: 0 PID: 2626 Comm: hwrng Not tainted 7.1.0-rc2+ #3 PREEMPTLAZY
>> [ 17.902197] Hardware name: 8335-GCA POWER8 (raw) 0x4d0200 opal:skiboot-5.4.8-5787ad3 PowerNV
>> [ 17.902204] NIP: c0000000000e7138 LR: c00800001ec8013c CTR: c0000000000e70fc
>> [ 17.902212] REGS: c000000092913c50 TRAP: 0300 Not tainted (7.1.0-rc2+)
>> [ 17.902222] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 44420220 XER: 20000000
>> [ 17.902269] CFAR: c00800001ec8026c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
>> GPR00: c00800001ec8013c c000000092913ef0 c000000001c18100 c00000002222d900
>> GPR04: c00000002222d900 0000000000000080 0000000000000001 0000000000000000
>> GPR08: 0000000000000000 c000000002212000 c0000000951e1780 c00800001ec80258
>> GPR12: c0000000000e70fc c00000ffff6fd700 c0000000001d11c0 c00000001b99b9c0
>> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> GPR24: 0000000000000000 c000000002fe6a58 0000000000000000 0000000000000000
>> GPR28: c000000002fe6a20 0000000000000010 000000000000000f c00000002222d900
>> [ 17.902406] NIP [c0000000000e7138] pnv_get_random_long+0x3c/0x114
>> [ 17.902426] LR [c00800001ec8013c] powernv_rng_read+0x78/0xc4 [powernv_rng]
>> [ 17.902444] Call Trace:
>> [ 17.902448] [c000000092913ef0] [c000000092913f30] 0xc000000092913f30 (unreliable)
>> [ 17.902463] [c000000092913f30] [c000000000decd58] hwrng_fillfn+0xd4/0x3dc
>> [ 17.902484] [c000000092913f90] [c0000000001d1328] kthread+0x170/0x1a4
>> [ 17.902498] [c000000092913fe0] [c00000000000d030] start_kernel_thread+0x14/0x18
>> [ 17.902513] Code: 60000000 7d2000a6 71290010 418200bc e94d0908 812a0000 39290001 912a0000 e90d0030 3d220060 39299f00 7d08482a <e9280000> 7c0004ac e8e90000 0c070000
>> [ 17.902569] ---[ end trace 0000000000000000 ]---
>> [ 18.008801] pstore: backend (nvram) writing error (-1)
>>
>> [ 18.015458] note: hwrng[2626] exited with irqs disabled
>> [ 18.015483] note: hwrng[2626] exited with preempt_count 1
>> ```
>>
>> Please find the output of `dmesg` attached.
>
> This is from my yesterday's boot test log in my P8, did not see this fail.
>
> root@ltcppm1:~# uname -a
> Linux ltcppm1.ltc.tadn.ibm.com 7.1.0-rc2-00021-gf583bd5f64d4 #1 SMP PREEMPT Wed May 6 00:55:45 EDT 2026 ppc64le GNU/Linux
> root@ltcppm1:~# dmesg
> [ 0.000000] [ T0] random: crng init done
> [ 0.000000] [ T0] hash-mmu: Page sizes from device-tree:
> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0
> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=16, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=7
> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=24, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=56
> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1
> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=24, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=8
> [ 0.000000] [ T0] hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0
> [ 0.000000] [ T0] hash-mmu: base_shift=34: shift=34, sllp=0x0120, avpnm=0x000007ff, tlbiel=0, penc=3
> [ 0.000000] [ T0] Enabling pkeys with max key count 32
> [ 0.000000] [ T0] Activating Kernel Userspace Access Prevention
> [ 0.000000] [ T0] Activating Kernel Userspace Execution Prevention
> [ 0.000000] [ T0] hash-mmu: Page orders: linear mapping = 24, virtual = 16, io = 16, vmemmap = 24
> [ 0.000000] [ T0] hash-mmu: Using 1TB segments
> [ 0.000000] [ T0] hash-mmu: Initializing hash mmu with SLB
> [ 0.000000] [ T0] Linux version 7.1.0-rc2-00021-gf583bd5f64d4
> (root@ltcppm1.ltc.tadn.ibm.com) (gcc (GCC) 16.1.1 20260501 (Red Hat 16.1.1-1), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT Wed May 6 00:55:45 EDT 2026
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000039c00000..0x000000003b6801ff (27136 KiB) map non-reusable ibm,firmware-allocs-memory@39c00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000800000000..0x0000000800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@800000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001000000000..0x0000001000dc01ff (14080 KiB) map non-reusable ibm,firmware-allocs-memory@1000000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001800000000..0x0000001800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@1800000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030000000..0x00000000302fffff (3072 KiB) map non-reusable ibm,firmware-code@30000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031000000..0x0000000031bfffff (12288 KiB) map non-reusable ibm,firmware-data@31000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030300000..0x0000000030ffffff (13312 KiB) map non-reusable ibm,firmware-heap@30300000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031c00000..0x0000000033fdffff (36736 KiB) map non-reusable ibm,firmware-stacks@31c00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd510000..0x0000001ffd69ffff (1600 KiB) map non-reusable ibm,hbrt-code-image@1ffd510000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd6a0000..0x0000001ffd6fffff (384 KiB) map non-reusable ibm,hbrt-target-image@1ffd6a0000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd700000..0x0000001ffd7fffff (1024 KiB) map non-reusable ibm,hbrt-vpd-image@1ffd700000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffda00000..0x0000001ffdafffff (1024 KiB) map non-reusable ibm,slw-image@1ffda00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffde00000..0x0000001ffdefffff (1024 KiB) map non-reusable ibm,slw-image@1ffde00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe200000..0x0000001ffe2fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe200000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe600000..0x0000001ffe6fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe600000
> [ 0.000000] [ T0] Found initrd at 0xc000000006a40000:0xc00000000815ae9e
> [ 0.000000] [ T0] Hardware name: 8247-22L POWER8E (raw) 0x4b0201 opal:skiboot-v5.4.12 PowerNV
> [ 0.000000] [ T0] printk: legacy bootconsole [udbg0] enabled
> [ 0.000000] [ T0] CPU maps initialized for 8 threads per core
> [ 0.000000] [ T0] (thread shift is 3)But I my opal version 5.4.12.
>
> Thanks for reporting the issue, will have an look at it.
I bisected it to a change between 5.19-rc3 and 5.19-rc4, and merge
commit 8100775d59a6 (Merge tag 'powerpc-5.19-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) [1] indeed
has rng related changes
> - Three fixes to wire up our various RNGs earlier in boot so they're
> available for use in the initial seeding in random_init().
> [ 0.000000] [ T0] Allocated 4608 bytes for 160 pacas
> [ 0.000000] [ T0]
> -----------------------------------------------------
>
> .......
>
> [ 37.407674] [ T900] audit: type=1130 audit(1778043621.931:10): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-monitor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> [ 37.413015] [ T900] audit: type=1130 audit(1778043621.937:11): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> [ 38.448156] [ T2286] powernv_rng: Registered powernv hwrng.
> [ 38.575227] [ T2264] tg3 0005:09:00.1 enP5p9s0f1: renamed from eth1
> [ 38.582176] [ T2223] tg3 0005:09:00.2 enP5p9s0f2: renamed from eth2
> ........
>
> ////cpuinfo output
>
> processor : 159
>
> cpu : POWER8E (raw), altivec supported
> clock : 2061.000000MHz
> revision : 2.1 (pvr 004b 0201)
>
> timebase : 512000000
> platform : PowerNV
> model : 8247-22L
> machine : PowerNV 8247-22L
> firmware : OPAL
> MMU : Hash
>
>
> But my system opal version 5.4.12.
> Thanks for reporting the issue, will have an look at it.
Thank you.
Kind regards,
Paul
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8100775d59a6789c3c6c309de26fac52f129cba8
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox