From: Jongwon Lee <ai@linux.com>
To: 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>
Cc: Ira Weiny <iweiny@kernel.org>, Li Ming <ming.li@zohomail.com>,
Richard Cheng <icheng@nvidia.com>,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/2] cxl/edac: Fix event record lookups for memory repair
Date: Sun, 01 Nov 2026 10:34:18 +0900 [thread overview]
Message-ID: <20261101013418.87326-1-ai@linux.com> (raw)
Patch 2 is the DPA flag masking fix from v2. Sashiko's review of v2
pointed out that the repair path reads cached DRAM event records with
no lock that keeps the event path from freeing them [1]. That race was
already there in cxl_find_rec_dram() and cxl_mem_perform_sparing(); v2
added one more read of a record, in the General Media lookup.
Patch 1 fixes the race for the DRAM lookup and the sparing path. Patch 2
does its General Media lookup under the same lock.
I used xa_lock() instead of RCU freeing. The cached records are copies
of the spec-defined event structures, so kfree_rcu() would need a
wrapper struct with an rcu_head, and the lookups only compare a few
fields. Taking device_lock() in the repair path, as the event path does,
looked like it could deadlock against unbind, where the EDAC sysfs
files are removed with device_lock() held.
Changes in v3:
- New patch 1 for the record lifetime race (Sashiko)
- Patch 2: General Media lookup under the xarray lock, returns bool
Changes in v2:
- Moved the Claude Code note below the --- (Dave Jiang)
v2: https://lore.kernel.org/r/20261031161121.15948-1-ai@linux.com
v1: https://lore.kernel.org/r/20261030072721.31970-1-ai@linux.com
Testing, QEMU master (b574eaf) with a CXL type 3 device, region
committed, KASAN and PROVE_LOCKING on:
- Same test as v1/v2: DRAM events injected at 0x1001, 0x2000 and
0x3002, then a repair requested through mem_repair0..4 for six DPAs.
Results match v2 for all five repair types.
- Race test: the host injects DRAM events every 20 ms (the same DPA
again and again, so xa_store() replaces and frees records, plus enough
distinct DPAs to hit the 200-record overflow path) while the guest
requests repairs in a loop on all five mem_repair devices, 300 s.
A test-only mdelay(20) after xa_load() widens the window.
Unpatched: KASAN slab-use-after-free in cxl_find_rec_dram(), called
from cxl_do_mem_sparing(). v3, delay inside the locked section: 3780
repair requests, no KASAN, lockdep or WARN output.
Without the delay neither kernel reported anything in 600 s.
This series was developed with Claude Code.
[1] https://lore.kernel.org/r/sashiko-outbox-192042@kernel.org
Jongwon Lee (2):
cxl/edac: Read cached DRAM event records under the xarray lock
cxl/edac: Mask DPA flags in the event record cache key
drivers/cxl/core/edac.c | 112 ++++++++++++++++++++++++++--------------
1 file changed, 73 insertions(+), 39 deletions(-)
base-commit: cf15f9f2361dd4002203716b7b878393c0eee4bf
--
2.55.0
next reply other threads:[~2026-11-01 1:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 1:34 Jongwon Lee [this message]
2026-11-01 1:34 ` [PATCH v3 1/2] cxl/edac: Read cached DRAM event records under the xarray lock Jongwon Lee
2026-11-02 7:56 ` Richard Cheng
2026-11-01 1:34 ` [PATCH v3 2/2] cxl/edac: Mask DPA flags in the event record cache key Jongwon Lee
2026-11-02 8:30 ` Richard Cheng
2026-11-02 7:41 ` [PATCH v3 0/2] cxl/edac: Fix event record lookups for memory repair 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=20261101013418.87326-1-ai@linux.com \
--to=ai@linux.com \
--cc=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=djbw@kernel.org \
--cc=icheng@nvidia.com \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.li@zohomail.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®