[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <170311143880.2826.17853753430536108145.stgit@bgt-140510-bm01.eng.stellus.in>
Date: Wed, 20 Dec 2023 22:58:12 +0000
From: Jim Harris <jim.harris@...sung.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>, "linux-pci@...r.kernel.org"
<linux-pci@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, Leon Romanovsky <leonro@...dia.com>, "Jason
Gunthorpe" <jgg@...dia.com>, Alex Williamson <alex.williamson@...hat.com>
Subject: [PATCH 0/2] pci/iov: avoid device_lock() when reading sriov_numvfs
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(-)
--
Powered by blists - more mailing lists