Re: [PATCH 2/4] PCI: Return -ETIMEOUT when reset readiness polling expires

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: breaking reset fallback leaves devices permanently wedged on timeout
--

commit 4617b1cca51c668aae8c9b4809552b80cdac13dd
Author: Richard Cheng <icheng@nvidia.com>

PCI: Return -ETIMEOUT when reset readiness polling expires

This patch modifies pci_dev_wait() to return -ETIMEDOUT instead of
-ENOTTY when a device fails to become ready. The commit message notes
this stops the reset-method fallback.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 6461274bdbcf9..d59a374a350d8 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1279,7 +1279,7 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
>  		if (delay > timeout) {
>  			pci_err(dev, "not ready %dms after %s; giving up\n",
>  				delay - 1, reset_type);
> -			return -ENOTTY;
> +			return -ETIMEDOUT;
>  		}

[Severity: High]
Will this regression leave devices permanently wedged if they hang during a
soft reset like a function level reset?

Looking at __pci_reset_function_locked() in drivers/pci/pci.c:

	for (i = 0; i < ARRAY_SIZE(pci_reset_fn_methods); i++) {
		...
		rc = method->reset_fn(dev, false);
		...
		if (rc != -ENOTTY)
			return rc;
	}

The fallback loop aborts on any error other than -ENOTTY.

Previously, if a device hung during a function level reset and
pci_dev_wait() timed out, it would return -ENOTTY. This allowed the
fallback mechanism to try a stronger reset method like a secondary bus
reset to recover the device.

By stopping this fallback, could userspace applications and virtual machine
guests using vfio permanently wedge an assigned device that has a buggy
reset implementation, instead of falling back to a secondary bus reset?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929020405.9724-1-icheng@nvidia.com?part=2