mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Richard Cheng <icheng@nvidia.com>
To: Jongwon Lee <ai@linux.com>
Cc: 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>, Ira Weiny <iweiny@kernel.org>,
	Li Ming <ming.li@zohomail.com>,
	 linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/2] cxl/edac: Fix event record lookups for memory repair
Date: Mon, 2 Nov 2026 15:41:49 +0800	[thread overview]
Message-ID: <aug-fvSTBNsdUd9J@MWDK4CY14F> (raw)
In-Reply-To: <20261101013418.87326-1-ai@linux.com>

On Sun, Nov 01, 2026 at 10:34:18AM +0800, Jongwon Lee wrote:
> 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.
>

Hi Jongwon,

Small nit, if you don't mind maybe place the description of patch 1
before patch 2, that will help us when reviewing.

Some comments in the following patches, thanks.

Best regards,
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)
> 
> 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
> 
> 

      parent reply	other threads:[~2026-11-02  7:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-01  1:34 Jongwon Lee
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-02 12:32     ` Jongwon Lee
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 12:32     ` Jongwon Lee
2026-11-02  7:41 ` Richard Cheng [this message]

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=aug-fvSTBNsdUd9J@MWDK4CY14F \
    --to=icheng@nvidia.com \
    --cc=ai@linux.com \
    --cc=alison.schofield@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=djbw@kernel.org \
    --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®