Linux kernel (drivers/pci): Pci_dev_lock() and the sysfs SR-IOV path took the device lock and the config-space access

Impact

Pci_dev_lock() and the sysfs SR-IOV path took the device lock and the config-space access lock in opposite orders, so a device reset racing an SR-IOV VF enable/disable deadlocks permanently. Both threads hang in D state holding the PCI device lock, which wedges every subsequent operation on that device - VF provisioning, reset, unbind - and the only way out is a reboot of the node all the tenants are sharing.

Who can reach it

Both halves are reachable in a normal passthrough cluster. A tenant holding /dev/vfio/* can call VFIO_DEVICE_RESET, which goes through pci_dev_lock() - that is side A and needs no host privilege. Side B is the operator's own VF lifecycle: writing to sysfs sriov_numvfs to hand out or reclaim VFs, which reaches pci_cfg_access_lock() through vfio_pci_core_sriov_configure() and pci_disable_sriov(). A tenant that resets its device in a loop while the control plane is reprovisioning VFs on the same PF can win the interleaving. Requires SR-IOV to be in use on the node.

What to do

Update to a kernel carrying the fix (no fixed_in published by the CNA; the stable commits below are widely backported). Interim: serialise VF provisioning against tenant activity - stop the tenant workload and revoke the VFIO device node before changing sriov_numvfs on a PF, rather than reconfiguring VFs while tenants are live on the same PF.

References