All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wandun Chen" <chenwandun1@gmail.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v6 09/10] of: reserved_mem: mark /memreserve/ entries as MEMBLOCK_NODUMP
Date: Wed, 02 Sep 2026 09:02:11 +0000	[thread overview]
Message-ID: <20260902090211.9DA891F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902073116.802752-10-chenwandun1@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] FDT /memreserve/ entries marked as MEMBLOCK_NODUMP can be later freed to the buddy allocator, causing active kernel memory to be silently omitted from crash dumps.
- [Medium] 64-bit FDT reserve entries are checked for overlap in 64-bit space but implicitly truncated to phys_addr_t when marked as NODUMP, potentially corrupting dumpable regions on 32-bit systems.
--

commit f6e6bcd14fb6f4946f258fc34089bbbdcd52f624
Author: Wandun Chen <chenwandun@lixiang.com>

of: reserved_mem: mark /memreserve/ entries as MEMBLOCK_NODUMP

This patch marks /memreserve/ entries in the device tree as MEMBLOCK_NODUMP
so they are excluded from kernel crash dumps. It explicitly leaves regions
that overlap with a dumpable region unmarked.

> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index f29a07e8fb23e..a42cf6eac55b5 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
[ ... ]
> @@ -251,6 +251,39 @@ static void __init __rmem_check_for_overlap(void)
>  	}
>  }
>  
> +void __init fdt_mark_memreserve_nodump(void)
> +{
> +	u64 base, size;
> +	int n;
> +	const void *fdt = initial_boot_params;
> +
> +	if (!IS_ENABLED(CONFIG_CRASH_DUMP))
> +		return;
> +
> +	if (!fdt)
> +		return;
> +
> +	for (n = 0; ; n++) {
> +		int i;
> +
> +		if (fdt_get_mem_rsv(fdt, n, &base, &size))
> +			break;
> +		if (!size)
> +			break;
> +
> +		for (i = 0; i < reserved_mem_count; i++) {
> +			struct reserved_mem *rmem = &reserved_mem[i];
> +
> +			if (rmem->dumpable &&
> +			    base < (u64)rmem->base + (u64)rmem->size &&
> +			    (u64)rmem->base < base + size)
> +				break;
> +		}
> +		if (i == reserved_mem_count)
> +			memblock_mark_nodump(base, size);

[Severity: Medium]
Will this corrupt dumpable regions on 32-bit systems?

base and size are u64, so the overlap check evaluates safely in 64-bit
space. However, memblock_mark_nodump() takes phys_addr_t. On 32-bit
systems, could a 64-bit FDT reserve entry > 4GB correctly pass the overlap
check above, but then get implicitly truncated to a 32-bit address when
passed to memblock_mark_nodump(), incorrectly marking a lower 32-bit
physical address as NODUMP without having checked it for overlap?

[Severity: High]
Can this cause active kernel memory to be silently omitted from crash dumps?

If the bootloader specifies a /memreserve/ entry for memory that the kernel
later frees (such as the initrd), this memory is returned to the buddy
allocator.

Since the MEMBLOCK_NODUMP flag is never cleared, will this cause reused
pages to be incorrectly skipped and omitted from the crash dump later on?

> +	}
> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902073116.802752-1-chenwandun1@gmail.com?part=9

  reply	other threads:[~2026-09-02  9:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  7:31 [PATCH v6 00/10] kdump: reduce vmcore size and capture time Wandun Chen
2026-09-02  7:31 ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 01/10] mm: memblock: add missing HugeTLB flag name Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:43   ` sashiko-bot
2026-09-02  7:31 ` [PATCH v6 02/10] riscv: build crash_mem ranges from memblock instead of resource tree Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 03/10] crash_core: fold duplicated memblock arch hooks into the weak default Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 04/10] crash_core: serialize crash header preparation against hotplug Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 05/10] crash_core: replace for_each_mem_range() with for_each_mem_region() Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 06/10] memblock: introduce MEMBLOCK_NODUMP flag Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 07/10] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  7:31 ` [PATCH v6 08/10] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-03  7:32   ` Marek Szyprowski
2026-09-03  7:32     ` Marek Szyprowski
2026-09-02  7:31 ` [PATCH v6 09/10] of: reserved_mem: mark /memreserve/ entries as MEMBLOCK_NODUMP Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  9:02   ` sashiko-bot [this message]
2026-09-03  7:32   ` Marek Szyprowski
2026-09-03  7:32     ` Marek Szyprowski
2026-09-02  7:31 ` [PATCH v6 10/10] crash_core: skip MEMBLOCK_NODUMP regions when building vmcore ELF header Wandun Chen
2026-09-02  7:31   ` Wandun Chen
2026-09-02  8:53 ` [PATCH v6 00/10] kdump: reduce vmcore size and capture time Baoquan He
2026-09-02  8:53   ` Baoquan He
2026-09-03  7:05   ` Wandun
2026-09-03  7:05     ` Wandun
2026-09-03  7:31     ` Baoquan He
2026-09-03  7:31       ` Baoquan He
2026-09-03  7:43       ` Wandun
2026-09-03  7:43         ` Wandun
2026-09-03  9:38         ` Baoquan He
2026-09-03  9:38           ` Baoquan He
2026-09-04 11:08           ` Chen Wandun
2026-09-04 11:08             ` Chen 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=20260902090211.9DA891F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=chenwandun1@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.