Re: [PATCH v29 4/5] sfc: obtain and map cxl range using devm_cxl_probe_mem

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Resource Teardown Ordering Violation in efx_pci_remove
- [High] Missing Hardware State Restoration for CXL HDM Decoders After FLR
--

commit cd561fb9993e195accb646b7a8524a13a2dd0b79
Author: Alejandro Lucero <alucerop@amd.com>
Subject: sfc: obtain and map cxl range using devm_cxl_probe_mem

This commit introduces CXL support to the sfc driver by creating a CXL
memory device using devm_cxl_probe_mem() and mapping the CXL range for
CTPIO buffer usage.

> diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> --- a/drivers/net/ethernet/sfc/efx.c
> +++ b/drivers/net/ethernet/sfc/efx.c
> @@ -984,6 +984,7 @@ static void efx_pci_remove(struct pci_dev *pci_dev)
>  	efx_fini_io(efx);
>  
>  	probe_data = container_of(efx, struct efx_probe_data, efx);
> +	efx_cxl_exit(probe_data);

[Severity: High]
Does this tear down resources in the correct order?

efx_fini_io() calls pci_disable_device() which disables memory decoding for
the endpoint.

Because the CXL memdev and its sysfs interfaces are managed by devres
(created via devm_cxl_probe_mem() during probe), they remain active until
devres_release_all() runs after efx_pci_remove() returns.

If userspace (e.g., CXL utilities, udev) accesses the CXL sysfs attributes
in this window, the CXL core will attempt to read memory-mapped component
registers on the disabled device.

Could this result in PCIe Unsupported Requests (UR) and a fatal AER fault or
kernel panic?

>  
>  	pci_dbg(efx->pci_dev, "shutdown successful\n");

[ ... ]

> diff --git a/drivers/net/ethernet/sfc/efx_cxl.c b/drivers/net/ethernet/sfc/efx_cxl.c
> --- a/drivers/net/ethernet/sfc/efx_cxl.c
> +++ b/drivers/net/ethernet/sfc/efx_cxl.c

[ ... ]

> @@ -73,9 +74,31 @@ int efx_cxl_init(struct efx_probe_data *probe_data)
>  		return -ENODEV;
>  	}
>  
> +	cxl->cxlmd = devm_cxl_probe_mem(&cxl->cxlds, &cxl_pio_range);

[Severity: High]
Is there a mechanism to restore the CXL HDM decoders after a Function Level
Reset (FLR)?

When the driver performs a device reset via pci_reset_function() (e.g.,
during efx_mcdi_reset() in drivers/net/ethernet/sfc/mcdi.c to recover from
an MCDI timeout), the PCIe endpoint undergoes an FLR. This wipes the
internal device state, including the CXL Component Registers and HDM
decoders.

While the PCI core automatically saves and restores standard configuration
space, it does not restore the memory-mapped CXL HDM decoders.

Without notifying the CXL core or manually re-initializing the CXL DPA
capacity and reprogramming the HDM decoders, the device silently stops
decoding the physical address range mapped to cxl->ctpio_cxl.

Could subsequent PIO packet transmissions to the ctpio_cxl mapping trigger
PCIe Unsupported Requests (UR) and lead to AER faults or kernel panics?

> +	if (IS_ERR(cxl->cxlmd)) {
> +		pci_err(pci_dev, "CXL accel memdev creation failed\n");
> +		return PTR_ERR(cxl->cxlmd);
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260622124010.2192888-1-alejandro.lucero-palau@amd.com?part=4