Re: [PATCH v10 06/12] cxl: Add CXL Device Reset helper

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:
- [Medium] The polling loop in cxl_reset_wait_cache_wbi() misses a final st=
ate check upon timeout and is vulnerable to returning a false timeout (-ETI=
MEDOUT) if the thread is preempted.
- [Low] usleep_range() is called with an overly tight 1-microsecond delta, =
preventing timer slack batching.
--

--- Patch [6]: [PATCH v10 06/12] cxl: Add CXL Device Reset helper ---
commit 7129cc4ec4e3e4cb936b9c61b556eecc1cfb46fa
Author: Srirangan Madhavan <[email protected]>

cxl: Add CXL Device Reset helper

Add an internal CXL Device Reset helper for Type 2 functions that advertise
CXL Reset in the CXL Device DVSEC. The helper disables CXL.cache, performs
cache writeback, initiates reset, waits for completion, and re-enables
CXL.cache.

> diff --git a/drivers/cxl/core/resource.c b/drivers/cxl/core/resource.c
> --- a/drivers/cxl/core/resource.c
> +++ b/drivers/cxl/core/resource.c

[ ... ]

> +static int cxl_reset_wait_cache_wbi(struct pci_dev *pdev, int dvsec)
> +{
> +	unsigned long deadline;
> +	u16 status2;
> +	int rc;
> +
> +	rc =3D cxl_reset_set_ctrl2(pdev, dvsec, PCI_DVSEC_CXL_INIT_CACHE_WBI);
> +	if (rc)
> +		return rc;
> +
> +	deadline =3D jiffies + usecs_to_jiffies(CXL_CACHE_WBI_TIMEOUT_US);
> +	do {
> +		usleep_range(CXL_CACHE_WBI_POLL_US, CXL_CACHE_WBI_POLL_US + 1);

[Severity: Low]
This isn't a bug, but does this 1-microsecond delta defeat the high-resolut=
ion
timer subsystem's ability to coalesce timer wakeups?

Could we use a wider range here to allow timer slack batching and reduce CPU
overhead?

> +
> +		rc =3D pci_read_config_word(pdev, dvsec + PCI_DVSEC_CXL_STATUS2,
> +					  &status2);
> +		if (rc)
> +			return pcibios_err_to_errno(rc);
> +		if (status2 !=3D U16_MAX && (status2 & PCI_DVSEC_CXL_CACHE_INV))
> +			return 0;
> +	} while (time_before(jiffies, deadline));
> +
> +	return -ETIMEDOUT;
> +}

[Severity: Medium]
Is this loop missing a final state check upon timeout?

If the thread is preempted or experiences a scheduling delay immediately
after reading the hardware status but before evaluating time_before(), and =
the
delay pushes jiffies past the deadline, the loop will exit and return
-ETIMEDOUT.

Could this return a false timeout if the hardware actually completed the
operation during that scheduling delay? Unlike cxl_reset_wait_done(), which
correctly handles this with a final check, this loop appears vulnerable.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804192958.1823=
[email protected]?part=3D6