Re: [PATCH v16 3/7] PCI: Fail FLR when config space is inaccessible

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Logic Error in Reset Capability Probing (Permanent Loss of FLR Support)
- [High] Un-ratelimited Warning Log Flooding (Denial of Service)
--

commit d8b99b3d5048ef035997beff7b1d31f361be5f9b
Author: Farhan Ali <alifm@linux.ibm.com>

PCI: Fail FLR when config space is inaccessible

This commit adds a check to validate if a device's config space is
accessible before performing an FLR reset. If the config space is not
accessible, the reset fails early.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
[ ... ]
> @@ -4396,6 +4396,9 @@ int pcie_reset_flr(struct pci_dev *dev, bool probe)
>  	if (!(dev->devcap & PCI_EXP_DEVCAP_FLR))
>  		return -ENOTTY;
>  
> +	if (!pci_dev_config_accessible(dev, "FLR"))

Does this fast-fail path bypass the 60-second blocking timeout previously
enforced by pci_dev_wait() when reading ~0 from an inaccessible config
space?

Looking at pci_dev_config_accessible(), it prints an un-ratelimited warning
if the config space is inaccessible. If an unprivileged user or VM guest
repeatedly triggers a reset on a passed-through PCI device via the
VFIO_DEVICE_RESET ioctl, could this flood the kernel log and overwhelm the
host console?

> +		return -ENOTTY;
> +
>  	if (probe)
>  		return 0;

If a device is temporarily inaccessible during system initialization or sysfs
writes when pcie_reset_flr() is called with probe=true, will this falsely
report that the device does not support FLR?

It appears this would cause the PCI subsystem to permanently omit the FLR
method from the device's cached capability list, preventing the device from
ever using FLR even after the link state recovers.

Does this also cause normal lockless capability queries to trigger active PCI
config reads and spurious kernel warnings?

Would it be better to move the accessibility check after the probe check?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514180059.1553-1-alifm@linux.ibm.com?part=3