Thread (20 messages) 20 messages, 3 authors, 2026-07-28

Re: [PATCH v4 00/10] kdump: reduce vmcore size and capture time

From: Rob Herring <robh@kernel.org>
Date: 2026-07-23 23:41:31
Also in: kexec, linux-devicetree, linux-iommu, linux-riscv, lkml, loongarch

On Tue, Jun 30, 2026 at 03:47:04PM +0800, Wandun Chen wrote:
From: Wandun Chen <redacted>

On SoCs that carve out large firmware-owned reserved memory (GPU
firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
those carveouts as part of system RAM even though their contents are
firmware state that is not useful for kernel crash analysis.
What about reserved regions on ACPI based systems?
This series introduces an opt-in 'dumpable' flag [1] on struct
reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
DT-based architectures (arm64, riscv, loongarch). By default reserved
regions are treated as non-dumpable; CMA regions are explicitly opted
in because their pages are returned to the buddy allocator and may
carry key crash-analysis data.
I never like seeing the same change being made to each architecture. 
That's generally a sign of restructuring needed. loongarch and arm64 
prepare_elf_headers() look about the same. riscv version uses 
walk_system_ram_res() for some reason. 

Perhaps the dumpable flag belongs in memblock instead? Then at least we 
wouldn't need more DT APIs exposed to the arch code, and the code stays 
independent of the firmware API.

I'd really like Marek's review on the reserved memory code changes.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help