If SR-IOV enabled device is held by vfio, and device is removed, vfio will hold device lock and notify userspace of the removal. If userspace reads sriov_numvfs sysfs entry, that thread will be blocked since sriov_numvfs_show() also tries to acquire the device lock. If that same thread is responsible for releasing the device to vfio, it results in a deadlock. One patch was proposed to add a separate mutex, specifically for struct pci_sriov, to synchronize access to sriov_numvfs in the sysfs paths (replacing use of the device_lock()). Leon instead suggested just reverting the commit 35ff867b765 which introduced device_lock() in the store path. This also led to a small fix around ordering on the kobject_uevent() when sriov_numvfs is updated. Ref: https://lore.kernel.org/linux-pci/ZXJI5+f8bUelVXqu@ubuntu/ --- Jim Harris (2): Revert "PCI/IOV: Serialize sysfs sriov_numvfs reads vs writes" pci/iov: fix kobject_uevent() ordering in sriov_enable() drivers/pci/iov.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) --
