From: Richard Cheng <icheng@nvidia.com>
To: jic23@kernel.org, dave@stgolabs.net, dave.jiang@intel.com,
alison.schofield@intel.com, vishal.l.verma@intel.com
Cc: iweiny@kernel.org, ming.li@zohomail.com, kaihengf@nvidia.com,
kobak@nvidia.com, newtonl@nvidia.com, kristinc@nvidia.com,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,
Richard Cheng <icheng@nvidia.com>
Subject: [PATCH v8 0/4] cxl: Repair poison enumeration regressions
Date: Tue, 22 Sep 2026 18:11:25 +0800 [thread overview]
Message-ID: <20260922101129.52794-1-icheng@nvidia.com> (raw)
This series repairs four poison enumeration regressions introduced by
commit be5cbd084027 ("cxl: Kill enum cxl_decoder_mode"). It groups the
remaining poison fixes from v7 [1] into a poison repair set.
Patch 1: cxl_get_poison_unmapped() ends the partition walk when it
encounters a fully mapped partition. Continue to the next partition
instead, so unmapped poison in later partitions is still collected.
Patch 2: the unmapped scan tolerates -EFAULT for RAM partitions but
leaves the error in rc. If no later query overwrites rc, enumeration
incorrectly reports failure. Clear rc before continuing past the
tolerated error.
Patch 3: use the ctx->offset handoff from the committed-decoder walk
as the starting point for the unmapped scan. Starting after the highest
DPA allocation leaves ranges allocated to uncommitted decoders
unqueried. Resume at the committed boundary and scan later partitions
from their beginning.
Patch 4: cxl_get_poison_by_memdev() can overwrite an earlier partition
query failure with a later success. Stop on the first error that is
not already tolerated as a RAM -EFAULT, preserving the failure.
In v7 [1] patch 6's review, Jonathan also noted that
cxl_internal_send_cmd() documents -EFAULT as a hardware error.
I will send a separate patch to clarify its mapping from the Invalid
Physical Address device response.
Changes since v7 [1]:
- Retain v7 patches 2–5, renumbered as patches 1–4, and rebase onto
current cxl/next.
- Drop v7 patches 1 and 7, which have been applied to cxl/next.
- Drop v7 patch 6 because the zero-sized HDM decoder series [2]
already fixes its negative partition-index access. Specifically,
commit 00f9ef9ad1ce ("cxl/hdm: Allow zero sized HDM decoders") [3]
guards the partition lookup while allowing the decoder walk to continue.
- Expand patch 2's commit message to explain how a RAM poison query
produces -EFAULT and why that response is tolerated.
[1]:
https://lore.kernel.org/linux-cxl/20260902053839.25595-1-icheng@nvidia.com/
[2]:
https://lore.kernel.org/linux-cxl/20260914090858.19181-1-icheng@nvidia.com/
[3]:
https://lore.kernel.org/linux-cxl/20260914090858.19181-3-icheng@nvidia.com/
Richard Cheng (4):
cxl/region: Scan all partitions for unmapped poison
cxl/region: Don't leak tolerated RAM -EFAULT from unmapped poison scan
cxl/region: Start unmapped poison scan at the committed decoder
boundary
cxl/memdev: Don't overwrite the error from an earlier partition poison
query
drivers/cxl/core/memdev.c | 2 ++
drivers/cxl/core/region.c | 13 ++++++-------
2 files changed, 8 insertions(+), 7 deletions(-)
base-commit: f2e9991100c903ec2d8eb62c3a1d6e0b9c67432e
--
2.43.0
next reply other threads:[~2026-09-22 10:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 10:11 Richard Cheng [this message]
2026-09-22 10:11 ` [PATCH v8 1/4] cxl/region: Scan all partitions for unmapped poison Richard Cheng
2026-09-22 10:11 ` [PATCH v8 2/4] cxl/region: Don't leak tolerated RAM -EFAULT from unmapped poison scan Richard Cheng
2026-09-22 10:11 ` [PATCH v8 3/4] cxl/region: Start unmapped poison scan at the committed decoder boundary Richard Cheng
2026-09-22 10:11 ` [PATCH v8 4/4] cxl/memdev: Don't overwrite the error from an earlier partition poison query Richard Cheng
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=20260922101129.52794-1-icheng@nvidia.com \
--to=icheng@nvidia.com \
--cc=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kaihengf@nvidia.com \
--cc=kobak@nvidia.com \
--cc=kristinc@nvidia.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=newtonl@nvidia.com \
--cc=vishal.l.verma@intel.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®