Re: [PATCH] PCI: lock upstream bridge in pci_try_reset_function()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Eagerly trylocking the shared upstream bridge introduces spurious -EAGAIN failures for concurrent resets of sibling devices (e.g., Virtual Functions).
--

--- Patch [1]: [PATCH] PCI: lock upstream bridge in pci_try_reset_function() ---
commit 26cda84dc0be3f7ffec20ace1e3feba4ee2b0184
Author: Runyu Xiao <[email protected]>

PCI: lock upstream bridge in pci_try_reset_function()

This commit updates pci_try_reset_function() to trylock the upstream bridge
before locking the target device. This ensures bridge configuration access
is serialized during a secondary-bus reset fallback.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 77b17b13ee615..c18aed839a866 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5282,20 +5282,33 @@ EXPORT_SYMBOL_GPL(pci_reset_function_locked);
>   */
>  int pci_try_reset_function(struct pci_dev *dev)
>  {
> +	struct pci_dev *bridge;
>  	int rc;
>  
>  	if (!pci_reset_supported(dev))
>  		return -ENOTTY;
>  
> -	if (!pci_dev_trylock(dev))
> +	bridge = pci_upstream_bridge(dev);
> +	if (bridge && !pci_dev_trylock(bridge))
>  		return -EAGAIN;

[Severity: High]
Does eagerly trylocking the shared upstream bridge introduce spurious -EAGAIN
failures for concurrent resets of sibling devices?

When concurrent threads open sibling Virtual Functions (which share the same
physical function and thus the same upstream bridge) via
vfio_pci_core_enable(), both threads invoke pci_try_reset_function(). 

The first thread successfully acquires pci_dev_trylock(bridge). The second
thread fails the trylock and immediately returns -EAGAIN. 

VFIO treats -EAGAIN as a fatal error during initialization, which can cause VM
startups or userspace applications opening multiple passed-through VFs
concurrently to fail spuriously.

Before this patch, VF resets (typically using Function Level Reset) executed
in parallel since they only locked the target device, not the shared bridge.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1