mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
	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>, Richard Cheng <icheng@nvidia.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 0/5] cxl, mm: Keep device-reported poison out of the page allocator
Date: Fri, 16 Oct 2026 21:42:06 +0100	[thread overview]
Message-ID: <20261016214206.1dc8484a@jic23-hlaptop> (raw)
In-Reply-To: <20261010162017.62506-1-shaikhkamal2012@gmail.com>

On Sat, 10 Oct 2026 21:50:08 +0530
Shaikh Kamaluddin <shaikhkamal2012@gmail.com> wrote:

> A CXL memory device keeps its own poison list: the DPAs it knows to be
> bad. The list lives on the device, so it survives a host reboot, a power
> cycle, and moving the device to another host.

That is a bit too general + needs backing with specific spec references.
I'm not sure for instance if there are any guarantees around poison
lists for volatile as some errors detected by local ECC will be intermittent
anyway.

I may have forgotten it but I don't recall the CXL spec talking at all
about any long term tracking of errors in volatile memory across power
cycles.  There are interfaces to test memory to detect stuck bits but
I don't think there is any requirement to run them at device boot (and
we haven't enabled them in linux yet as on demand things).


> 
> Linux reads that list only when user space writes trigger_poison_list.
> Nothing reads it when a region is assembled, so with a device that
> already has poison:
> 
>   1. the RAM region is assembled and dax/kmem onlines it;
>   2. every frame enters the buddy allocator, including the ones the
>      device would have named had anyone asked;
>   3. a task is handed one and reads it: machine check, memory_failure(),
>      SIGBUS.
> 
> This series reads the poison list at region probe, before the range is
> onlined, and keeps the frames it covers out of the allocator. Nothing is
> unmapped or signalled, and no runtime path changes: the frames never
> enter the allocator, so this is not forwarding latent poison to
> memory_failure().
> 
> Dependency
> ==========
> 
> This is built on Breno Leitao's hwpoison series [1], which keeps frames
> poisoned before a kexec out of the next kernel's allocator. The approach
> here, withholding frames as they are onlined rather than taking them
> back out later, follows [1]. [1] hooks __free_pages_core(), splits a
> block around its bad frames, and marks them with hwpoison_boot_page().
> Patch 4 adds a second source to that hook.
> 
> The two cover different cases. [1] records frames in a bitmap spanning
> the RAM the EFI memory map describes. Memory hot-added after boot sits
> outside it, and CXL region memory is hot-added after boot. [1] also
> carries its record across kexec only, while the device's list survives
> reboot and migration.

The CXL region - may be hot added after boot.  Whilst I like that model,
on many existing systems the CXL subsystem is just identifying what
was already there.

> 
> Applies on next-20260908 plus [1] v5. The num_poisoned_pages_inc()
> change agreed for v6 [2] does not touch these patches. Patches 1, 2 and
> 5 touch only drivers/cxl; patches 3 and 4 touch mm.
> 
> Design
> ======
> 
> Which records are withheld. A corrected error never reaches the poison
> list, so every record is uncorrectable. Only records with source
> Internal, a failure of the device's own media, are withheld. External
> poison was written by the host into healthy media and a rewrite recovers
> it; Injected poison comes from the Inject Poison test command. Withholding
> either would make a recoverable state permanent.

At best a detection of an ECC error in local media is a hint that it
might not be cleared by a suitable full cache line write.

> 
> No host-side storage. The device is the source of truth and is re-read
> on every probe. When a location is repaired (sPPR, sparing, hPPR) the

It might well be repaired just fine by a host write assuming the CPU
arch supports clearing poison that way. Ideally we'd poke it some to 
find out whether it is recoverable.

> device drops it from the list, and the next probe onlines the frame
> again. A record persisted by the host could not learn about the repair.
> 
> Volatile ranges. CXL r3.2 8.2.9.8.4.1:
> 
>   If the device does not support poison list for volatile ranges and any
>   location in the requested list maps to volatile, the device shall
>   return Invalid Physical Address.
> 
> A device that returns it, or that has no Get Poison List at all, is
> onlined as today with nothing withheld. This is also the reason for the
> RAM -EFAULT tolerance poison_by_decoder() has carried, without a comment,
> since f0832a586396 ("cxl/region: Provide region info to the cxl_poison
> trace event").
> 
> Incomplete lists. If the device reports overflow, the host stops at
> max_errors with more records pending, or a media scan is in progress,
> region probe fails rather than onlining on a partial list.

This bit needs shout more about as you just stopped region probe
on regions that previously probed (but would potentially return poison
on some memory).  I'd put a Note: Will stop regions probing if poison list
has overflowed. right at the top of this cover letter. 

I'm not necessarily against this. I need to think a bit more on the impacts.

Certainly an interesting patch set.

> prerequisite-patch-id: a23fe88ab4529b6a6669a991e15cf1631311391c
> prerequisite-patch-id: 111c69880ed0e148cdda285896c006e8d1fc98a8


      parent reply	other threads:[~2026-10-16 20:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10 16:20 Shaikh Kamaluddin
2026-10-10 16:20 ` [RFC PATCH 1/5] cxl/mbox: Add Get Poison List snapshot support Shaikh Kamaluddin
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-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-16 22:35   ` Jonathan Cameron
2026-10-16 20:42 ` Jonathan Cameron [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=20261016214206.1dc8484a@jic23-hlaptop \
    --to=jic23@kernel.org \
    --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=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=shaikhkamal2012@gmail.com \
    --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®