From: Richard Cheng <icheng@nvidia.com>
To: dave@stgolabs.net, jic23@kernel.org, dave.jiang@intel.com,
alison.schofield@intel.com, vishal.l.verma@intel.com,
djbw@kernel.org, danwilliams@nvidia.com
Cc: iweiny@kernel.org, ming.li@zohomail.com, gourry@gourry.net,
rrichter@amd.com, linux-cxl@vger.kernel.org,
linux-kernel@vger.kernel.org, kees@kernel.org,
newtonl@nvidia.com, kristinc@nvidia.com, mochs@nvidia.com,
kaihengf@nvidia.com, kobak@nvidia.com,
Richard Cheng <icheng@nvidia.com>
Subject: [PATCH v3 0/5] cxl: Sashiko bug fixes
Date: Wed, 8 Jul 2026 15:42:23 +0800 [thread overview]
Message-ID: <20260708074228.43654-1-icheng@nvidia.com> (raw)
Five independent, pre-existing bugs in the CXL core, reported by
sashiko.
Patch 1: Get/Set Feature derive each mailbox command's offset from the
starting offset plus the amount of data already transferred, then store
it in a 16-bit field. A large offset/count supplied through fwctl can
cause a later offset to exceed the representable feature extent and be
truncated by cpu_to_le16(), targeting the wrong feature data. Reject
invalid ranges up front.
Change cxl_get_feature() to return ssize_t so invalid input and mailbox
failures are reported as negative errno instead of being conflated with
a zero-byte result. Update all EDAC callers for the signed return
contract while preserving the existing fwctl RPC response behavior.
Patch 2: cxl_get_poison_unmapped() aborted its whole partition sweep on
the first fully-mapped partition, silently skipping unmapped poison in
all later partitions. Skip that partition instead.
Patch 3: the same function tolerated the -EFAULT a RAM partition returns
for Get Poison List but left it in rc, so a benign fault on the last
scanned partition surfaced as a spurious read failure. Clear rc, as
poison_by_decoder() already does.
Patch 4: the same function also ignored the ctx->offset handoff from
poison_by_decoder() and derived its scan start from the highest DPA
allocation, so the DPA of allocated-but-uncommitted decoders was never
scanned by either phase. Resume the sweep at ctx->offset.
Patch 5: cxl_get_poison_by_memdev() overwrote rc on each partition
query, so an earlier partition's failure was masked by a later success
and unscanned poison was reported as a clean list. Stop on any error
not tolerated as a RAM -EFAULT.
Changes since v2 [1]:
- Patch 1: change cxl_get_feature() to return ssize_t and propagate
negative errno through all callers while preserving fwctl behavior
(Dave)
- No code changes to patches 2-5
[1]:
https://lore.kernel.org/linux-cxl/20260702090849.47501-1-icheng@nvidia.com/
Richard Cheng (5):
cxl/features: Reject feature offset that overflows 16-bit field
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/core.h | 2 +-
drivers/cxl/core/edac.c | 20 +++++++++++++++-----
drivers/cxl/core/features.c | 22 +++++++++++++++-------
drivers/cxl/core/memdev.c | 2 ++
drivers/cxl/core/region.c | 13 ++++++-------
5 files changed, 39 insertions(+), 20 deletions(-)
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
--
2.43.0
next reply other threads:[~2026-07-08 7:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 7:42 Richard Cheng [this message]
2026-07-08 7:42 ` [PATCH v3 1/5] cxl/features: Reject feature offset that overflows 16-bit field Richard Cheng
2026-07-08 7:58 ` sashiko-bot
2026-07-08 7:42 ` [PATCH v3 2/5] cxl/region: Scan all partitions for unmapped poison Richard Cheng
2026-07-08 7:42 ` [PATCH v3 3/5] cxl/region: Don't leak tolerated RAM -EFAULT from unmapped poison scan Richard Cheng
2026-07-08 7:53 ` sashiko-bot
2026-07-08 7:42 ` [PATCH v3 4/5] cxl/region: Start unmapped poison scan at the committed decoder boundary Richard Cheng
2026-07-08 7:58 ` sashiko-bot
2026-07-08 7:42 ` [PATCH v3 5/5] cxl/memdev: Don't overwrite the error from an earlier partition poison query Richard Cheng
2026-07-08 7:55 ` 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=20260708074228.43654-1-icheng@nvidia.com \
--to=icheng@nvidia.com \
--cc=alison.schofield@intel.com \
--cc=danwilliams@nvidia.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=djbw@kernel.org \
--cc=gourry@gourry.net \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kaihengf@nvidia.com \
--cc=kees@kernel.org \
--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=mochs@nvidia.com \
--cc=newtonl@nvidia.com \
--cc=rrichter@amd.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 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.