[PATCH v4 00/10] kdump: reduce vmcore size and capture time
Rob Herring
robh at kernel.org
Thu Jul 23 16:41:26 PDT 2026
On Tue, Jun 30, 2026 at 03:47:04PM +0800, Wandun Chen wrote:
> From: Wandun Chen <chenwandun at lixiang.com>
>
> 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
More information about the linux-riscv
mailing list