From: sashiko-bot@kernel.org
To: "Wandun Chen" <chenwandun1@gmail.com>,
robh@kernel.org, baoquan.he@linux.dev, rppt@kernel.org,
m.szyprowski@samsung.com
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
chenhuacai@kernel.org, kernel@xen0n.name, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
saravanak@kernel.org, akpm@linux-foundation.org,
pasha.tatashin@soleen.com, pratyush@kernel.org,
ruirui.yang@linux.dev, robin.murphy@arm.com,
devicetree@vger.kernel.org, kexec@lists.infradead.org,
linux-mm@kvack.org, conor+dt@kernel.org
Subject: Re: [PATCH v9 7/8] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP
Date: Thu, 22 Oct 2026 08:33:17 +0000 [thread overview]
Message-ID: <sashiko-outbox-181183@kernel.org> (raw)
In-Reply-To: <20261021083011.2170525-8-chenwandun1@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] of: reserved_mem: unaligned memblock split in fdt_mark_reserve_mem_nodump()
- [Medium] of: reserved_mem: fdt_mark_reserve_mem_nodump() marks failed reservations
--
commit a452b9d1fad838de511c25fe48e4541c58357355
Author: Wandun Chen <chenwandun@lixiang.com>
of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP
This commit adds fdt_mark_reserve_mem_nodump() to mark non-dumpable
reserved-memory regions in memblock.memory so kdump omits them from the
vmcore when crash dump support is enabled.
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 8c9d6395d6a39..db2bf76000d23 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -677,6 +677,24 @@ static void __init fdt_init_reserved_mem_node(unsigned long node, const char *un
> reserved_mem_count++;
> }
>
> +void __init fdt_mark_reserve_mem_nodump(void)
> +{
> + struct reserved_mem *rmem;
> + int i;
> +
> + if (!IS_ENABLED(CONFIG_CRASH_DUMP))
> + return;
> +
> + if (!IS_ENABLED(CONFIG_KEXEC_FILE) && !IS_ENABLED(CONFIG_CRASH_HOTPLUG))
> + return;
> +
> + for (i = 0; i < reserved_mem_count; i++) {
> + rmem = &reserved_mem[i];
> + if (rmem->size && !rmem->dumpable)
> + memblock_mark_nodump(rmem->base, rmem->size);
> + }
[Severity: High]
What happens here when rmem->base or rmem->size is not page-aligned, or
when rmem->size is smaller than a page?
Previously, mapped reserved-memory regions were only recorded in
memblock.reserved and did not split memblock.memory. Calling
memblock_mark_nodump() splits memblock.memory at rmem->base and
rmem->base + rmem->size, but reserved-memory regions are not guaranteed to
be page-aligned:
drivers/of/of_reserved_mem.c:early_init_dt_alloc_reserved_memory_arch() {
end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
align = !align ? SMP_CACHE_BYTES : align;
base = memblock_phys_alloc_range(size, align, start, end);
}
Static device tree regions without no-map can also be smaller than a page
or unaligned to the page size (for example, cfe-stub@0 in
arch/arm64/boot/dts/broadcom/bcmbca/bcm4908.dtsi with a 0x1000 size under
16k or 64k page configurations).
When memblock.memory is split at an unaligned or sub-page boundary,
__next_mem_pfn_range() rounds each region inward to page boundaries and
skips sub-page regions:
mm/memblock.c:__next_mem_pfn_range() {
while (++*idx < type->cnt) {
r = &type->regions[*idx];
r_nid = memblock_get_region_node(r);
if (PFN_UP(r->base) >= PFN_DOWN(r->base + r->size))
continue;
}
This drops any page frame straddling an unaligned split boundary from
for_each_mem_pfn_range() and the page allocator.
In addition, request_standard_resources() in arch/arm64/kernel/setup.c and
init_resources() in arch/riscv/kernel/setup.c register each mapped
memblock.memory region using memblock_region_memory_base_pfn() and
memblock_region_memory_end_pfn():
arch/riscv/kernel/setup.c:init_resources() {
res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
ret = add_resource(&iomem_resource, res);
if (ret < 0)
goto error;
}
For a sub-page region where PFN_UP(base) >= PFN_DOWN(base + size), res->end
becomes smaller than res->start (or underflows when end_pfn is 0), causing
add_resource() on riscv to fail and tear down iomem_resource, and producing
an inverted or underflowed resource on arm64.
Splitting memblock.memory also splits hyp_memory[] on arm64 pkvm, where
check_range_allowed_memory() in arch/arm64/kvm/hyp/nvhe/mem_protect.c
requires checked ranges to fall within a single region:
arch/arm64/kvm/hyp/nvhe/mem_protect.c:check_range_allowed_memory() {
reg = find_mem_range(start, &range);
if (!is_in_mem_range(end - 1, &range))
return -EINVAL;
}
Could memblock_mark_nodump() corrupt resource registration, drop straddling
pages, or break pkvm range checks when regions are not page-aligned?
[Severity: Medium]
Can fdt_mark_reserve_mem_nodump() also end up marking active kernel memory
as non-dumpable if an early static reservation failed?
During early boot in fdt_scan_reserved_mem(), __reserved_mem_reserve_reg()
logs an error if early_init_dt_reserve_memory() fails (for example, if a
static region overlaps the kernel image or initrd), but still returns 0:
drivers/of/of_reserved_mem.c:__reserved_mem_reserve_reg() {
if (size && early_init_dt_reserve_memory(base, size, nomap) == 0) {
fdt_fixup_reserved_mem_node(node, base, size);
pr_debug("Reserved memory: reserved region for node '%s': base %pa, size %lu MiB\n",
uname, &base, (unsigned long)(size / SZ_1M));
} else {
pr_err("Reserved memory: failed to reserve memory for node '%s': base %pa, size %lu MiB\n",
uname, &base, (unsigned long)(size / SZ_1M));
}
return 0;
}
Later, fdt_scan_reserved_mem_late() scans all available static nodes in
/reserved-memory and passes them to fdt_init_reserved_mem_node(), recording
them in reserved_mem[] regardless of whether the early reservation
succeeded:
drivers/of/of_reserved_mem.c:fdt_scan_reserved_mem_late() {
if (size) {
uname = fdt_get_name(fdt, child, NULL);
fdt_init_reserved_mem_node(child, uname, base, size);
}
}
Wouldn't fdt_mark_reserve_mem_nodump() then mark that unreserved range in
memblock.memory, causing kdump to omit memory that is actually in use by
the kernel?
> +}
> +
> struct rmem_assigned_device {
> struct device *dev;
> struct reserved_mem *rmem;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261021083011.2170525-1-chenwandun1@gmail.com?part=7
next prev parent reply other threads:[~2026-10-22 8:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 8:30 [PATCH v9 0/8] kdump: reduce vmcore size and capture time Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-21 8:30 ` [PATCH v9 1/8] riscv: build crash_mem ranges from memblock instead of resource tree Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-21 9:05 ` Jinjie Ruan
2026-10-21 9:05 ` Jinjie Ruan
2026-10-22 8:33 ` sashiko-bot
2026-10-21 8:30 ` [PATCH v9 2/8] crash_core: fold duplicated memblock arch hooks into the weak default Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-22 8:33 ` sashiko-bot
2026-10-21 8:30 ` [PATCH v9 3/8] crash_core: serialize crash header preparation against hotplug Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-21 9:10 ` Jinjie Ruan
2026-10-21 9:13 ` Jinjie Ruan
2026-10-21 9:13 ` Jinjie Ruan
2026-10-21 9:48 ` Wandun
2026-10-21 9:48 ` Wandun
2026-10-22 2:00 ` Jinjie Ruan
2026-10-22 2:00 ` Jinjie Ruan
2026-10-22 7:44 ` Wandun
2026-10-22 7:44 ` Wandun
2026-10-22 8:33 ` sashiko-bot
2026-10-21 8:30 ` [PATCH v9 4/8] crash_core: replace for_each_mem_range() with for_each_mem_region() Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-22 8:33 ` sashiko-bot
2026-10-21 8:30 ` [PATCH v9 5/8] memblock: introduce MEMBLOCK_NODUMP flag Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-22 8:33 ` sashiko-bot
2026-10-21 8:30 ` [PATCH v9 6/8] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-22 8:33 ` sashiko-bot
2026-10-21 8:30 ` [PATCH v9 7/8] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-22 8:33 ` sashiko-bot [this message]
2026-10-21 8:30 ` [PATCH v9 8/8] crash_core: skip MEMBLOCK_NODUMP regions when building vmcore ELF header Wandun Chen
2026-10-21 8:30 ` Wandun Chen
2026-10-22 8:33 ` sashiko-bot
2026-10-21 13:23 ` [PATCH v9 0/8] kdump: reduce vmcore size and capture time Rob Herring
2026-10-21 13:23 ` Rob Herring
2026-10-22 7:04 ` Wandun
2026-10-22 7:04 ` Wandun
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=sashiko-outbox-181183@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=baoquan.he@linux.dev \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=chenwandun1@gmail.com \
--cc=conor+dt@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=kernel@xen0n.name \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=pasha.tatashin@soleen.com \
--cc=pjw@kernel.org \
--cc=pratyush@kernel.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=saravanak@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tglx@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.