From: Rob Herring <robh@kernel.org>
To: Wandun Chen <chenwandun1@gmail.com>
Cc: chenhuacai@kernel.org, kernel@xen0n.name, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, saravanak@kernel.org,
bhe@redhat.com, rppt@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
kexec@lists.infradead.org, iommu@lists.linux.dev,
zhaomeijing@lixiang.com, catalin.marinas@arm.com,
will@kernel.org, alex@ghiti.fr, akpm@linux-foundation.org,
pasha.tatashin@soleen.com, pratyush@kernel.org,
ruirui.yang@linux.dev, m.szyprowski@samsung.com,
robin.murphy@arm.com
Subject: Re: [PATCH v4 00/10] kdump: reduce vmcore size and capture time
Date: Thu, 23 Jul 2026 18:41:26 -0500 [thread overview]
Message-ID: <20260723234126.GA3253409-robh@kernel.org> (raw)
In-Reply-To: <20260630074715.4126796-1-chenwandun1@gmail.com>
On Tue, Jun 30, 2026 at 03:47:04PM +0800, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@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
prev parent reply other threads:[~2026-07-23 23:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 7:47 [PATCH v4 00/10] kdump: reduce vmcore size and capture time Wandun Chen
2026-06-30 7:47 ` [PATCH v4 01/10] kexec/crash: provide crash_exclude_mem_range() stub when CONFIG_CRASH_DUMP=n Wandun Chen
2026-06-30 11:05 ` Pratyush Yadav
2026-06-30 7:47 ` [PATCH v4 02/10] of: reserved_mem: dedup and relocate reserved-memory messages Wandun Chen
2026-06-30 7:47 ` [PATCH v4 03/10] of: reserved_mem: skip late scan when no regions are reserved Wandun Chen
2026-06-30 8:19 ` sashiko-bot
2026-06-30 7:47 ` [PATCH v4 04/10] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late() Wandun Chen
2026-06-30 7:47 ` [PATCH v4 05/10] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-06-30 7:47 ` [PATCH v4 06/10] of: reserved_mem: save /memreserve/ entries into the reserved_mem array Wandun Chen
2026-06-30 7:47 ` [PATCH v4 07/10] of: reserved_mem: add kdump helpers to exclude non-dumpable regions Wandun Chen
2026-06-30 11:06 ` Pratyush Yadav
2026-06-30 7:47 ` [PATCH v4 08/10] arm64: kdump: exclude non-dumpable reserved memory regions from vmcore Wandun Chen
2026-06-30 9:04 ` sashiko-bot
2026-06-30 11:06 ` Pratyush Yadav
2026-06-30 7:47 ` [PATCH v4 09/10] riscv: " Wandun Chen
2026-06-30 9:22 ` sashiko-bot
2026-06-30 11:12 ` Pratyush Yadav
2026-06-30 12:00 ` Wandun
2026-06-30 7:47 ` [PATCH v4 10/10] loongarch: " Wandun Chen
2026-06-30 9:37 ` sashiko-bot
2026-06-30 11:13 ` Pratyush Yadav
2026-07-22 12:07 ` [PATCH v4 00/10] kdump: reduce vmcore size and capture time Wandun
2026-07-23 23:41 ` Rob Herring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260723234126.GA3253409-robh@kernel.org \
--to=robh@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=chenwandun1@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=kernel@xen0n.name \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=loongarch@lists.linux.dev \
--cc=m.szyprowski@samsung.com \
--cc=palmer@dabbelt.com \
--cc=pasha.tatashin@soleen.com \
--cc=pjw@kernel.org \
--cc=pratyush@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=saravanak@kernel.org \
--cc=will@kernel.org \
--cc=zhaomeijing@lixiang.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox