lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ