From: sashiko-bot@kernel.org
To: "Breno Leitao" <leitao@debian.org>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Miaohe Lin" <linmiaohe@huawei.com>,
"Naoya Horiguchi" <nao.horiguchi@gmail.com>,
"Oscar Salvador" <osalvador@suse.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Danilo Krummrich" <dakr@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
kas@kernel.org, kexec@lists.infradead.org,
"Brendan Jackman" <brendan.jackman@linux.dev>,
"Johannes Weiner" <hannes@cmpxchg.org>, "Zi Yan" <ziy@nvidia.com>,
shakeel.butt@linux.dev
Cc: linux-cxl@vger.kernel.org, rmikey@meta.com, riel@surriel.com,
harry@kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v6 4/7] mm/memblock: add a reserved-region flag for poisoned frames
Date: Fri, 16 Oct 2026 12:26:22 +0000 [thread overview]
Message-ID: <sashiko-outbox-174292@kernel.org> (raw)
In-Reply-To: <20261016-hwpoison-kho-v6-4-f304255147da@debian.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: page-level sharing detection fails due to unaligned base check
--
commit 91f3abf246b482e4b3339361ad3572545e8e83f6
Author: Breno Leitao <leitao@debian.org>
mm/memblock: add a reserved-region flag for poisoned frames
This commit adds the MEMBLOCK_RSRV_HWPOISON flag to memblock to reserve
hardware-poisoned frames found by an earlier kernel. It introduces
memblock_reserve_hwpoison() to handle these reservations while attempting
to avoid overlap with existing reserved regions. Additionally, it ensures
these frames are flagged with PG_hwpoison instead of PG_reserved during
initialization.
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 31961ed628b0a..d20d99972a4db 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
[ ... ]
> @@ -1015,6 +1018,55 @@ int __init_memblock __memblock_reserve(phys_addr_t base, phys_addr_t size,
> return memblock_add_range(&memblock.reserved, base, size, nid, flags);
> }
>
> +int __init memblock_reserve_hwpoison(phys_addr_t base, phys_addr_t size)
> +{
> + phys_addr_t end = base + size;
> + bool reserved = false;
> + int err = 0;
> +
> + while (base < end) {
> + phys_addr_t next = end;
> + struct memblock_region *r;
> + bool covered = false;
> +
> + for_each_reserved_mem_region(r) {
> + if (r->base + r->size <= base)
> + continue;
> + if (r->base >= end)
> + break;
> + if (PAGE_ALIGN_DOWN(r->base) <= base) {
[Severity: High]
Does this byte-level check cause the loop to skip regions that share
the same page but end before the new reservation's base?
The commit message states that a page shared with an earlier reservation
stays with it, so no page is flagged twice. However, if an existing
reservation spans 0x1000-0x1100 and the new HWPOISON reservation requests
0x1800-0x1900 (both in the same 4KB page), 0x1100 <= 0x1800 is true.
This causes the loop to skip the region and bypass the subsequent
PAGE_ALIGN_DOWN overlap check, leading to the new region being reserved
alongside the old one.
If the prior reservation was a KERNEL reservation, the page erroneously
receives both PG_reserved and PG_hwpoison.
[ ... ]
> +/*
> + * Frames an earlier kernel found poisoned end up as a frame poisoned by this
> + * kernel would: PG_hwpoison, not PG_reserved. Holes in the range stay reserved.
> + */
> +static void __init memmap_init_hwpoison_range(phys_addr_t start,
> + phys_addr_t end, int nid)
> +{
> + unsigned long pfn;
> +
> + for_each_valid_pfn(pfn, PFN_DOWN(start), PFN_UP(end)) {
> + struct page *page = pfn_to_page(pfn);
> +
> + init_deferred_page(pfn, nid);
> +
> + if (memblock_is_map_memory(PFN_PHYS(pfn)))
> + hwpoison_boot_page(page);
[Severity: High]
Can this path execute multiple times for the same PFN when a page contains
multiple unmerged HWPOISON fragments?
Because of the unaligned base check bypass above,
memmap_init_reserved_pages() will process the same page twice. Since
hwpoison_boot_page() lacks a TestSetPageHWPoison() guard, it unconditionally
increments num_poisoned_pages and calls adjust_managed_page_count(page, 1)
on every invocation.
This artificially inflates both the global poisoned page count and the
zone's managed page count, potentially leading to page allocator
underflows and corrupted VM statistics.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016-hwpoison-kho-v6-0-f304255147da@debian.org?part=4
next prev parent reply other threads:[~2026-10-16 12:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 12:15 [PATCH v6 0/7] mm/memory-failure: keep hardware-poisoned pages out of the next kexec Breno Leitao
2026-10-16 12:15 ` [PATCH v6 1/7] mm/memory-failure: efi: add the LINUX_EFI_POISONED_MEMORY configuration table Breno Leitao
2026-10-16 12:22 ` sashiko-bot
2026-10-16 12:15 ` [PATCH v6 2/7] mm/memory-failure: libstub: install the poisoned-memory EFI table Breno Leitao
2026-10-16 12:24 ` sashiko-bot
2026-10-16 12:15 ` [PATCH v6 3/7] mm/memory-failure: add hwpoison_boot_page() to flag an inherited frame Breno Leitao
2026-10-16 12:29 ` sashiko-bot
2026-10-16 12:15 ` [PATCH v6 4/7] mm/memblock: add a reserved-region flag for poisoned frames Breno Leitao
2026-10-16 12:26 ` sashiko-bot [this message]
2026-10-16 12:15 ` [PATCH v6 5/7] drivers/base/memory: count the poison a block already holds when creating it Breno Leitao
2026-10-16 12:30 ` sashiko-bot
2026-10-16 12:15 ` [PATCH v6 6/7] mm/memory-failure: efi: reserve the inherited poisoned-memory units Breno Leitao
2026-10-16 12:24 ` sashiko-bot
2026-10-16 12:15 ` [PATCH v6 7/7] mm/memory-failure: efi: record hardware-poisoned frames into the poisoned-memory table Breno Leitao
2026-10-16 12:28 ` sashiko-bot
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-174292@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=brendan.jackman@linux.dev \
--cc=catalin.marinas@arm.com \
--cc=dakr@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=hpa@zytor.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=leitao@debian.org \
--cc=liam@infradead.org \
--cc=linmiaohe@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=rafael@kernel.org \
--cc=riel@surriel.com \
--cc=rmikey@meta.com \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=ziy@nvidia.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 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.