From: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>
To: Richard Cheng <icheng@nvidia.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jic23@kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dan Williams <djbw@kernel.org>, Miaohe Lin <linmiaohe@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
Breno Leitao <leitao@debian.org>, Ira Weiny <iweiny@kernel.org>,
Li Ming <ming.li@zohomail.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, David Hildenbrand <david@kernel.org>,
Oscar Salvador <osalvador@suse.de>,
Kiryl Shutsemau <kas@kernel.org>, Harry Yoo <harry@kernel.org>
Subject: Re: [RFC PATCH 4/5] mm/page_alloc: Keep pre-online poison out of the buddy allocator
Date: Fri, 23 Oct 2026 01:39:56 +0530 [thread overview]
Message-ID: <atptlI4Pstd70N9u@acer-nitro-anv15-41> (raw)
In-Reply-To: <atB-cL8x5CSMOHEP@MWDK4CY14F>
On Thu, Oct 15, 2026 at 03:27:54PM +0800, Richard Cheng wrote:
> On Sat, Oct 10, 2026 at 09:50:12PM +0800, Shaikh Kamaluddin wrote:
> > The inherited-poison path checks initialized blocks before releasing
> > them to the buddy allocator. CXL device poison discovered before
> > hot-added memory is onlined is recorded separately in the pre-online
> > poison registry.
> >
> > Extend __free_pages_core() to send a block to free_poisoned_block() when
> > it intersects either poison source. In free_poisoned_block(), withhold a
> > page when its PFN is registered as pre-online poison or its physical
> > address is present in the inherited-poison table.
> >
> > Pages identified by either source continue through
> > hwpoison_boot_page(), while clean pages are released through
> > accept_and_free_block().
> >
> > Signed-off-by: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>
> > ---
> > mm/page_alloc.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index cca67a2702a4..57843df01b2a 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -33,6 +33,7 @@
> > #include <linux/cpuset.h>
> > #include <linux/folio_batch.h>
> > #include <linux/memory_hotplug.h>
> > +#include <linux/memory-failure.h>
> > #include <linux/nodemask.h>
> > #include <linux/vmstat.h>
> > #include <linux/fault-inject.h>
> > @@ -1601,12 +1602,14 @@ static void __meminit free_poisoned_block(struct page *page, unsigned int order,
> > enum meminit_context context)
> > {
> > unsigned long i, nr_pages = 1UL << order;
> > + unsigned long pfn = page_to_pfn(page);
> >
> > for (i = 0; i < nr_pages; i++) {
> > struct page *p = page + i;
> > phys_addr_t phys = page_to_phys(p);
> >
> > - if (range_contains_poisoned_memory(phys, PAGE_SIZE)) {
> > + if (range_contains_poisoned_memory(phys, PAGE_SIZE) ||
> > + preonline_hwpoison_contains(pfn + i)) {
> > hwpoison_boot_page(p, context);
> > continue;
> > }
> > @@ -1652,7 +1655,8 @@ void __meminit __free_pages_core(struct page *page, unsigned int order,
> >
> > /* First: a block parked by __free_unaccepted() never returns here. */
> > if (range_contains_poisoned_memory(page_to_phys(page),
> > - PAGE_SIZE << order)) {
> > + PAGE_SIZE << order) ||
> > + preonline_hwpoison_intersects(page_to_pfn(page), nr_pages)) {
> > free_poisoned_block(page, order, context);
> > return;
> > }
> > --
> > 2.43.0
> >
>
> Hi Shaikh,
>
> I think the idea of discovering device poison first is good, but the boundary
> should be more strictly designed.
>
Thanks for the review, Richard.
> Now if I don't get it wrong, if we turn on memory_hotplug.memmap_on_memory,
> we can have part of CXL memory to do the bookkeeping for itself, without
> using the existing RAM.
>
> What if that bookkeeping part is poisoned ? the check ignores this situation
> right ?
Yes, you are right. With memmap_on_memory, each 128 MiB block's struct
pages are placed in its first 2 MiB (0x200 pages) by vmemmap_populate()
when the memory is added, and memory_block_online() then onlines only
start_pfn + 0x200 onwards. Those vmemmap pages never reach
__free_pages_core(), so the registry is never consulted for them.
I reproduced it in QEMU 9.1 (TCG) on next-20260908 + [1] v5 + this RFC,
with two Internal poison records in the first block: DPA 0x100000
(PFN 0x190100, inside the vmemmap area 0x190000-0x1901ff) and DPA
0x400000 (PFN 0x190400, outside it). Both are registered, but only
0x190400 is withheld.
Steps:
1. Config: CONFIG_SPARSEMEM_VMEMMAP=y, CONFIG_MHP_MEMMAP_ON_MEMORY=y.
2. Boot with memmap_on_memory, without auto-online:
vng --disable-kvm --run ./arch/x86/boot/bzImage \
--disable-microvm --memory 4G --cpus 4 \
--append "memory_hotplug.memmap_on_memory=1" \
--qemu-opts="-machine q35,cxl=on \
-object memory-backend-ram,id=vmem0,share=on,size=512M \
-device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
-device cxl-rp,port=0,bus=cxl.1,id=rp0,chassis=0,slot=2 \
-device cxl-type3,bus=rp0,volatile-memdev=vmem0,id=cxl-vmem0 \
-M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G \
-qmp unix:/tmp/qmp.sock,server=on,wait=off"
# cat /sys/module/memory_hotplug/parameters/memmap_on_memory
Y
3. Inject Internal poison over QMP (host):
{ "execute": "cxl-inject-poison",
"arguments": { "path": "/machine/peripheral/cxl-vmem0",
"start": 1048576, "length": 64 } }
{ "execute": "cxl-inject-poison",
"arguments": { "path": "/machine/peripheral/cxl-vmem0",
"start": 4194304, "length": 64 } }
4. Create the region with kmem not yet bound, then enable
memmap_on_memory on the dax device:
# grep MemTotal /proc/meminfo
MemTotal: 3999996 kB
# echo 0 > /sys/bus/dax/drivers_autoprobe
# cxl create-region -m -t ram -d decoder0.0 -w 1 mem0
cxl_region region0: withholding 2 frame(s) reported poisoned by the device
# echo 1 > /sys/bus/dax/devices/dax0.0/memmap_on_memory
5. Add and online the memory:
# daxctl reconfigure-device --mode=system-ram dax0.0
# lsmem
0x0000000190000000-0x00000001afffffff 512M online yes 50-53
6. Result:
# grep -E 'MemTotal|HardwareCorrupted' /proc/meminfo
MemTotal: 4516092 kB
HardwareCorrupted: 4 kB
# tools/mm/page-types -a 0x190000+0x20000 -b hwpoison -l
offset len flags
190400 1 ___________________X_______________________
MemTotal grows by 504 MiB rather than 512 MiB (4 blocks x 2 MiB of
memmap), so memmap_on_memory was in effect. Only 0x190400 is
hwpoisoned; 0x190100 holds struct pages.
>
> What about draw a clear line between normal RAM and hot-add CXL memory, have
> the latter gone through the thorough check and do the rest you want ?
>
> Best regards,
> Richard Cheng.
>
>
>
>
>
>
>
>
>
>
next prev parent reply other threads:[~2026-10-22 20:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 16:20 [RFC PATCH 0/5] cxl, mm: Keep device-reported poison out of the page allocator Shaikh Kamaluddin
2026-10-10 16:20 ` [RFC PATCH 1/5] cxl/mbox: Add Get Poison List snapshot support Shaikh Kamaluddin
2026-10-16 22:18 ` Jonathan Cameron
2026-10-10 16:20 ` [RFC PATCH 2/5] cxl/region: Factor decoder poison-list retrieval Shaikh Kamaluddin
2026-10-16 22:21 ` Jonathan Cameron
2026-10-10 16:20 ` [RFC PATCH 3/5] mm/memory-failure: Add a pre-online poison registry Shaikh Kamaluddin
2026-10-10 16:20 ` [RFC PATCH 4/5] mm/page_alloc: Keep pre-online poison out of the buddy allocator Shaikh Kamaluddin
2026-10-15 7:27 ` Richard Cheng
2026-10-22 20:09 ` Shaikh Kamaluddin [this message]
2026-10-10 16:20 ` [RFC PATCH 5/5] cxl/region: Register device poison before exposing RAM Shaikh Kamaluddin
2026-10-15 7:59 ` Richard Cheng
2026-10-19 20:00 ` Dave Jiang
2026-10-16 22:35 ` Jonathan Cameron
2026-10-16 20:42 ` [RFC PATCH 0/5] cxl, mm: Keep device-reported poison out of the page allocator Jonathan Cameron
2026-10-20 1:11 ` Alison Schofield
2026-10-21 20:18 ` Shaikh Kamaluddin
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=atptlI4Pstd70N9u@acer-nitro-anv15-41 \
--to=shaikhkamal2012@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=brendan.jackman@linux.dev \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=djbw@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=icheng@nvidia.com \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kas@kernel.org \
--cc=leitao@debian.org \
--cc=linmiaohe@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=ming.li@zohomail.com \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=vishal.l.verma@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®