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 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


             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®