mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 v4 0/2] cxl/edac: Fix event record lookups for memory repair
Date: Mon, 02 Nov 2026 21:32:33 +0900	[thread overview]
Message-ID: <20261102123233.74598-1-ai@linux.com> (raw)

Patch 1 fixes a use-after-free between the repair path and the event
path. 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]. The race was already there in cxl_find_rec_dram() and
cxl_mem_perform_sparing(). Patch 1 does the DRAM lookup under the xarray
lock and copies the matching record out for the sparing path.

Patch 2 is the DPA flag masking fix from v2. It also does the General
Media lookup under the same lock, since v2 added a read of that record.

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 v4:
- Patch 1: copy the whole struct cxl_event_dram out instead of only
  validity_flags (Richard Cheng)
- Patch 2: make cxl_rec_key() and cxl_rec_not_repairable() static
  inline (Richard Cheng)
- Cover letter: describe patch 1 first (Richard Cheng)

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)

v3: https://lore.kernel.org/r/20261101013418.87326-1-ai@linux.com
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 and a committed
region, on top of d89e1d186e. Debug options: KASAN, PROVE_LOCKING,
PROVE_RAW_LOCK_NESTING, PROVE_RCU, DEBUG_ATOMIC_SLEEP, DEBUG_LIST,
UBSAN_BOUNDS, KMEMLEAK, hung task and soft lockup detection, booted with
preempt=full.

- Repair table: DRAM events at 0x1001, 0x2000 and 0x3002 and General
  Media events at 0x5001 and 0x6002, then a repair request on all five
  mem_repair devices for eight DPAs. With v4, 0x1000 and 0x2000 succeed
  for all five repair types and 0x5000 succeeds for PPR only. 0x3000
  and 0x6000 (NOT_REPAIRABLE set), 0x7000 (no record), 0x1001 and
  0x3002 are rejected with -EINVAL. Unpatched, 0x1000 and the PPR
  request at 0x5000 fail, and 0x1001 and 0x3002 are accepted.
- Race test with a test-only mdelay(20): the host injects DRAM and
  General Media events with no gap, repeating some DPAs so that
  xa_store() replaces and frees records and adding enough distinct
  DPAs to reach the overflow path, while four guest loops request
  repairs on all five devices. Unpatched, delay after xa_load() and
  after the lookup in the sparing path: KASAN slab-use-after-free in
  cxl_do_mem_sparing() after 120 s, a 2-byte read of validity_flags in
  a record freed by cxl_store_rec_dram(). v4, delay after both
  xa_load() calls inside the locked section and after the lookup in
  the sparing path: 600 s, 11070 repair requests, 261973 events, no
  report.
- The same race test without the delay: v4 for 1800 s, 56460 repair
  requests and 786023 events; unpatched for 900 s, 24150 repair
  requests and 301280 events. Neither kernel reported anything.
- Unbind test: two repair loops and the event injection as above for
  600 s while a loop unbinds cxl_mem, waits 2 s, binds it and waits
  3 s. v4: 78 unbind/bind cycles, 7248 repair requests, no report,
  mem0 bound at the end.
- kmemleak scan at the end of each run: no unreferenced objects.
- Builds: W=1 after each patch, sparse, clang W=1 for x86_64 and arm64,
  and CONFIG_CXL_EDAC_MEM_REPAIR=n, with no new warnings. The series
  applies to cxl/next (cf15f9f236) and builds there.

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 | 115 ++++++++++++++++++++++++++--------------
 1 file changed, 76 insertions(+), 39 deletions(-)


base-commit: cf15f9f2361dd4002203716b7b878393c0eee4bf
-- 
2.55.0


             reply	other threads:[~2026-11-02 12:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 12:32 Jongwon Lee [this message]
2026-11-02 12:32 ` [PATCH v4 1/2] cxl/edac: Read cached DRAM event records under the xarray lock Jongwon Lee
2026-11-02 12:32 ` [PATCH v4 2/2] cxl/edac: Mask DPA flags in the event record cache key Jongwon Lee

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=20261102123233.74598-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®