Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Srirangan Madhavan" <smadhavan@nvidia.com>
Cc: linux-cxl@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v7 03/11] cxl: Cache endpoint decoder settings during PCI enumeration
Date: Tue, 23 Jun 2026 03:45:28 +0000	[thread overview]
Message-ID: <20260623034529.4875D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623032453.3404772-4-smadhavan@nvidia.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] Allocating devres resources during PCI device enumeration causes driver probing to fail permanently with -EBUSY.
- [High] devm_cxl_pci_setup_hdm_info() falsely rejects devices using DVSEC emulation when their DVSEC range count differs from their HDM decoder count.
- [Medium] Missing release/acquire memory barriers when publishing and consuming the `pdev->hdm` pointer allows concurrent readers to see uninitialized memory.
--

commit e3058b1fc7aea013a57ebe41db76dc923a188403
Author: Srirangan Madhavan <smadhavan@nvidia.com>

cxl: Cache endpoint decoder settings during PCI enumeration

Populate pci_dev->hdm from PCI capability initialization when a CXL.mem
function already has memory decoding enabled. This gives driver-free reset
paths an early HDM snapshot without enabling BAR decoding during
enumeration.

> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c
> index 83cda63f76a5a..0230ebfada42b 100644
> --- a/drivers/cxl/core/hdm.c
> +++ b/drivers/cxl/core/hdm.c
[ ... ]
> @@ -107,9 +105,27 @@ static int devm_cxl_pci_setup_hdm_info(struct cxl_hdm *cxlhdm)
>  	}
>  
>  	if (!dev_is_pci(uport))
> +		return NULL;
> +
> +	return to_pci_dev(uport);
> +}
> +
> +static int devm_cxl_pci_setup_hdm_info(struct cxl_hdm *cxlhdm)
> +{
> +	struct cxl_hdm_info *info;
> +	struct pci_dev *pdev;
> +
> +	pdev = cxl_hdm_to_pci_dev(cxlhdm);
> +	if (!pdev)
> +		return 0;
> +
> +	info = READ_ONCE(pdev->hdm);
> +	if (info) {
> +		if (info->decoder_count != cxlhdm->decoder_count)
> +			return -ENXIO;

[Severity: High]
Will this strict equality check reject valid devices that fall back to DVSEC
emulation?

When the cxl_port driver probes, devm_cxl_setup_hdm() might fall back to
DVSEC emulation, which overwrites the local cxlhdm->decoder_count with
the number of DVSEC ranges. If that happens, this check against the raw
hardware HDM count will fail and return -ENXIO, breaking the probe.

>  		return 0;
> +	}
>  
> -	pdev = to_pci_dev(uport);
>  	info = devm_kzalloc(&pdev->dev,
>  			    struct_size(info, settings, cxlhdm->decoder_count),
>  			    GFP_KERNEL);
[ ... ]
> diff --git a/drivers/cxl/core/reset.c b/drivers/cxl/core/reset.c
> index 14f024098e826..fc52d3abdb5b4 100644
> --- a/drivers/cxl/core/reset.c
> +++ b/drivers/cxl/core/reset.c
[ ... ]
> +int pci_cxl_hdm_init(struct pci_dev *pdev)
> +{
[ ... ]
> +	if (!info) {
> +		info = devm_kzalloc(&pdev->dev,
> +				    struct_size(info, settings,
> +						CXL_HDM_DECODER_MAX_COUNT),
> +				    GFP_KERNEL);

[Severity: Critical]
Does allocating devres memory during PCI enumeration prevent the device
from being probed later?

The driver core requires a device's devres_head to be empty before a
driver can bind to it. Since pci_cxl_hdm_init() is called during the early
pci_init_capabilities() enumeration phase, this devm_kzalloc() will attach
resources before probing. 

Will really_probe() then abort with a resources present before probing
error and permanently prevent the cxl_pci driver from binding to the device?

> +		if (!info)
> +			return -ENOMEM;
> +		allocated_info = true;
> +	}
[ ... ]
> +	settings = info->settings;
> +	for (int i = 0; i < info->decoder_count; i++) {
> +		rc = cxl_pci_hdm_read_decoder(pdev, &settings[i],
> +					      regs.hdm_decoder, i);
> +		if (rc)
> +			goto out_unmap;
> +	}
> +
> +	WRITE_ONCE(pdev->hdm, info);

[Severity: Medium]
Are memory barriers needed here to ensure the initialized memory is visible
before the pointer is published?

Since WRITE_ONCE() and READ_ONCE() do not provide SMP memory barriers,
can the CPU reorder the devm_kzalloc() memory zeroing after the pointer
publication? If a concurrent sysfs reader accesses the pointer, it could
potentially see a non-zero garbage value for info->regs.hdm_decoder.

> +	if (allocated_info) {
> +		rc = devm_add_action(&pdev->dev, cxl_pci_hdm_clear, pdev);
> +		if (rc) {
> +			WRITE_ONCE(pdev->hdm, NULL);
> +			goto out_unmap;
> +		}
> +	}
> +	return 0;
[ ... ]
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index b63cd0c310bc0..9e214446fd42f 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
[ ... ]
> @@ -2679,6 +2680,7 @@ static void pci_init_capabilities(struct pci_dev *dev)
>  	pci_rebar_init(dev);		/* Resizable BAR */
>  	pci_dev3_init(dev);		/* Device 3 capabilities */
>  	pci_ide_init(dev);		/* Link Integrity and Data Encryption */
> +	pci_cxl_hdm_init(dev);		/* CXL HDM Decoder Capability */
>  
>  	pcie_report_downtraining(dev);
>  	pci_init_reset_methods(dev);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623032453.3404772-1-smadhavan@nvidia.com?part=3

  reply	other threads:[~2026-06-23  3:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  3:24 [PATCH v7 00/11] PCI/CXL: Add CXL reset support for Type 2 devices Srirangan Madhavan
2026-06-23  3:24 ` [PATCH v7 01/11] cxl: Split decoder programming into a reusable helper Srirangan Madhavan
2026-06-23  3:42   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 02/11] cxl: Cache decoder settings on PCI devices Srirangan Madhavan
2026-06-23  3:42   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 03/11] cxl: Cache endpoint decoder settings during PCI enumeration Srirangan Madhavan
2026-06-23  3:45   ` sashiko-bot [this message]
2026-06-23  3:24 ` [PATCH v7 04/11] PCI: Export pci_dev_save_and_disable() and pci_dev_restore() Srirangan Madhavan
2026-06-23  3:34   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 05/11] cxl: Add CXL Device Reset helper Srirangan Madhavan
2026-06-23  3:36   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 06/11] cxl: Validate HDM ranges before CXL reset Srirangan Madhavan
2026-06-23  3:33   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 07/11] PCI/cxl: Discover the CXL reset scope Srirangan Madhavan
2026-06-23  3:34   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 08/11] cxl: Coordinate sibling functions for CXL reset Srirangan Madhavan
2026-06-23  3:42   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 09/11] cxl: Restore CXL HDM state after PCI reset Srirangan Madhavan
2026-06-23  3:39   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 10/11] PCI/cxl: Expose CXL Reset as a PCI reset method Srirangan Madhavan
2026-06-23  3:47   ` sashiko-bot
2026-06-23  3:24 ` [PATCH v7 11/11] Documentation/ABI: Document CXL Reset " Srirangan Madhavan
2026-06-23  3:35   ` sashiko-bot

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=20260623034529.4875D1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=smadhavan@nvidia.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