Linux CXL
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Dave Jiang" <dave.jiang@intel.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v4 2/3] cxl/core: Hold the dport host lock across dport lookup and use
Date: Thu, 01 Oct 2026 16:02:57 +0000	[thread overview]
Message-ID: <20261001160257.E0BEC1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261001154744.1095902-3-dave.jiang@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] cxl/core: AB-BA deadlock in RCH topologies due to child-to-parent lock inversion
--

commit 689adbac9a3f5c00d58408df886ec90fd00ca46d
Author: Dave Jiang <dave.jiang@intel.com>

cxl/core: Hold the dport host lock across dport lookup and use

Callers of cxl_pci_find_port() and cxl_mem_find_port() can be handed a
struct cxl_dport that is already freed, and all four dereference it
without the lock that would prevent that.
    
A dport is kzalloc()'d into a devres group on its host device, so it dies
when that host unbinds. The host is &port->dev for a switch port and
port->uport_dev for the root port.

> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c
> index 9d807c1a002ca..55a571f86d477 100644
> --- a/drivers/cxl/core/pci.c
> +++ b/drivers/cxl/core/pci.c
> @@ -734,10 +734,16 @@ int cxl_pci_setup_regs(struct pci_dev *pdev, enum cxl_regloc_type type,
>  	if (rc && type == CXL_REGLOC_RBI_COMPONENT && is_cxl_restricted(pdev)) {
>  		struct cxl_dport *dport;
>  		struct cxl_port *port __free(put_cxl_port) =
> -			cxl_pci_find_port(pdev, &dport);
> +			cxl_pci_find_port(pdev);
>  		if (!port)
>  			return -EPROBE_DEFER;
>  
> +		guard(device)(cxl_port_dport_host(port));

[Severity: High]
Does acquiring the ancestor host bridge lock here while the driver core holds
the descendant (pdev) device lock cause an AB-BA deadlock?

If concurrent device removal locks the parent device and then iterates to lock
children, could it deadlock against this path in cxl_pci_setup_regs() during
device probe?

> +
> +		dport = cxl_pci_find_dport(pdev, port);
> +		if (!dport)
> +			return -EPROBE_DEFER;
> +
>  		rc = cxl_rcrb_get_comp_regs(pdev, map, dport);
>  		if (rc)
>  			return rc;

[ ... ]

> diff --git a/drivers/cxl/core/ras_rch.c b/drivers/cxl/core/ras_rch.c
> index e0e01aa5eba6c..3c6aae26deedd 100644
> --- a/drivers/cxl/core/ras_rch.c
> +++ b/drivers/cxl/core/ras_rch.c
> @@ -118,10 +118,20 @@ void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds)
>  	int severity;
>  
>  	struct cxl_port *port __free(put_cxl_port) =
> -		cxl_pci_find_port(pdev, &dport);
> +		cxl_pci_find_port(pdev);
>  	if (!port)
>  		return;
>  
> +	/*
> +	 * The dport may have been freed since the lookup above, so take the
> +	 * lock that pins it and find it again.
> +	 */
> +	guard(device)(cxl_port_dport_host(port));

[Severity: High]
Could this also lead to an AB-BA deadlock on Restricted CXL Host (RCH)
topologies?

This acquires the ancestor host bridge lock while the caller holds the
descendant (&cxlmd->dev) device lock. Concurrent device hot-remove paths
typically lock from parent to child, which seems like it would deadlock against
this AER handling path.

> +
> +	dport = cxl_pci_find_dport(pdev, port);
> +	if (!dport)
> +		return;
> +
>  	if (!cxl_rch_get_aer_info(dport->regs.dport_aer, &aer_regs))
>  		return;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001154744.1095902-1-dave.jiang@intel.com?part=2

  reply	other threads:[~2026-10-01 16:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 15:47 [PATCH v4 0/3] cxl: dport fixes from sashiko reports Dave Jiang
2026-10-01 15:47 ` [PATCH v4 1/3] cxl/port: Clear cached dport pointers when a dport is removed Dave Jiang
2026-10-01 15:47 ` [PATCH v4 2/3] cxl/core: Hold the dport host lock across dport lookup and use Dave Jiang
2026-10-01 16:02   ` sashiko-bot [this message]
2026-10-01 17:36     ` Dave Jiang
2026-10-01 15:47 ` [PATCH v4 3/3] cxl/port: Attach endpoints to a dport under the lock that pins it 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=20261001160257.E0BEC1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dave.jiang@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox