All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alison Schofield <alison.schofield@intel.com>
To: Li Ming <ming.li@zohomail.com>
Cc: <sashiko-reviews@lists.linux.dev>, <linux-cxl@vger.kernel.org>
Subject: Re: [PATCH 2/2] cxl/region: Fill first free targets[] slot during auto-discovery
Date: Thu, 11 Jun 2026 18:19:00 -0700	[thread overview]
Message-ID: <aitehJe5yth4yaEB@aschofie-mobl2.lan> (raw)
In-Reply-To: <0df43a4c-cdb1-443e-a424-33ecc63d6c1d@zohomail.com>

On Mon, Jun 08, 2026 at 12:38:42PM +0800, Li Ming wrote:
> On 6/6/2026 4:11 PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> >
> > Pre-existing issues:
> > - [High] Loops iterating over the `p->targets` array up to `p->nr_targets` unconditionally dereference elements, leading to NULL pointer dereferences because the array can be sparse.
> > --
> >
> > commit bf78125f1b0b7a811b9b200d37ed57cc96619a00
> > Author: Li Ming <ming.li@zohomail.com>
> >
> > cxl/region: Fill first free targets[] slot during auto-discovery
> >
> > This commit adjusts the cxl_region_attach_auto logic to find the first free
> > target slot for endpoint decoder attachment, rather than appending to the tail.
> > This ensures NULL holes in the target array are filled to avoid accessing an
> > endpoint decoder via a NULL pointer and miscounting valid endpoint decoders.
> >
> >> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> >> index c4335ebf19f7f..532dac77bd003 100644
> >> --- a/drivers/cxl/core/region.c
> >> +++ b/drivers/cxl/core/region.c
> >> @@ -1848,8 +1848,21 @@ static int cxl_region_attach_auto(struct cxl_region *cxlr,
> >>  	 * this means that userspace can view devices in the wrong position
> >>  	 * before the region activates, and must be careful to understand when
> >>  	 * it might be racing region autodiscovery.
> >> +	 *
> >> +	 * The endpoint decoder will be recorded into the first free slot of
> >> +	 * the target array.
> >>  	 */
> >> -	pos = p->nr_targets;
> >> +	for (pos = 0; pos < p->interleave_ways; pos++) {
> >> +		if (!p->targets[pos])
> >> +			break;
> >> +	}
> >> +
> >> +	if (pos == p->interleave_ways) {
> >> +		dev_err(&cxlr->dev, "%s: unable to find a free target slot\n",
> >> +			dev_name(&cxled->cxld.dev));
> >> +		return -ENXIO;
> >> +	}
> >> +
> >>  	p->targets[pos] = cxled;
> > [Severity: High]
> > This is a pre-existing issue, but since __cxl_decoder_detach() can leave
> > sparse holes in p->targets without compacting the array, are the loops
> > that iterate up to p->nr_targets still susceptible to NULL pointer
> > dereferences?
> >
> > For instance, in drivers/cxl/core/region.c:cxl_dpa_to_hpa():
> >
> >     for (int i = 0; i < p->nr_targets; i++) {
> >         if (cxlmd == cxled_to_memdev(p->targets[i])) {
> >
> > If there is a hole at an index less than p->nr_targets, wouldn't
> > cxled_to_memdev() dereference a NULL pointer?
> >
> > Similar unprotected iterations seem to exist in
> > cxl_scrub_get_attrbs_region(), unaligned_region_offset_to_dpa_result(),
> > and region_offset_to_dpa_result().
> >
> > Does the array need to be compacted upon detach, or should these loops be
> > updated to check for NULL pointers before dereferencing p->targets[i]?
> 
> It is not a bug here.
> 
> cxl driver always calls cxl_dpa_to_region() for a cxl region checking before involving cxl_dpa_to_hpa(), but if a cxl region is not bound to cxl region driver, driver will not involve cxl_dpa_to_hpa().
> 
> But maybe adding cxlr->driver checking in cxl_dpa_to_hpa() is a choice.
> 

Hi Ming, 
I'm in agreemnet that there is not a reachable NULL deref path here.
With this patch, the hole is gone by the time those loops run.

A hole only exists transiently between a detach and the next stage,
while the region is not comitted. The windows suggested aren't real.

I'm kind of against adding an explicit check in cxl_dpa_to_hpa(), as
'hardening' because that undercuts this whole point here.

-- Alison



> >
> >>  	cxled->pos = pos;
> >>  	cxled->state = CXL_DECODER_STATE_AUTO_STAGED;
> 
> 
> 

  reply	other threads:[~2026-06-12  1:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-06  7:50 [PATCH 0/2] cxl/region: Fix two decoder attach/detach issues for auto-assembly region Li Ming
2026-06-06  7:51 ` [PATCH 1/2] cxl/region: Fix out-of-bounds access in cxl_cancel_auto_attach() Li Ming
2026-06-12  1:19   ` Alison Schofield
2026-06-06  7:51 ` [PATCH 2/2] cxl/region: Fill first free targets[] slot during auto-discovery Li Ming
2026-06-06  8:11   ` sashiko-bot
2026-06-08  4:38     ` Li Ming
2026-06-12  1:19       ` Alison Schofield [this message]
2026-06-12  1:20   ` Alison Schofield
2026-06-12 16:40 ` [PATCH 0/2] cxl/region: Fix two decoder attach/detach issues for auto-assembly region Dave Jiang

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=aitehJe5yth4yaEB@aschofie-mobl2.lan \
    --to=alison.schofield@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=ming.li@zohomail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.