summaryrefslogtreecommitdiffstats
path: root/drivers/s390
diff options
context:
space:
mode:
authorAlex Williamson <alex.williamson@redhat.com>2015-07-24 15:14:04 -0600
committerAlex Williamson <alex.williamson@redhat.com>2015-07-24 15:14:04 -0600
commit4bc94d5dc95d3a2159d821b39277477e69507f67 (patch)
tree29bbb204346c7deb81532ae3d25b16ac9bd017a8 /drivers/s390
parentafdf0b91bdf04bc66ee64e1ac44f0979c55749b1 (diff)
downloadlinux-4bc94d5dc95d3a2159d821b39277477e69507f67.tar.bz2
vfio: Fix lockdep issue
When we open a device file descriptor, we currently have the following: vfio_group_get_device_fd() mutex_lock(&group->device_lock); open() ... if (ret) release() If we hit that error case, we call the backend driver release path, which for vfio-pci looks like this: vfio_pci_release() vfio_pci_disable() vfio_pci_try_bus_reset() vfio_pci_get_devs() vfio_device_get_from_dev() vfio_group_get_device() mutex_lock(&group->device_lock); Whoops, we've stumbled back onto group.device_lock and created a deadlock. There's a low likelihood of ever seeing this play out, but obviously it needs to be fixed. To do that we can use a reference to the vfio_device for vfio_group_get_device_fd() rather than holding the lock. There was a loop in this function, theoretically allowing multiple devices with the same name, but in practice we don't expect such a thing to happen and the code is already aborting from the loop with break on any sort of error rather than continuing and only parsing the first match anyway, so the loop was effectively unused already. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Fixes: 20f300175a1e ("vfio/pci: Fix racy vfio_device_get_from_dev() call") Reported-by: Joerg Roedel <joro@8bytes.org> Tested-by: Joerg Roedel <jroedel@suse.de>
Diffstat (limited to 'drivers/s390')
0 files changed, 0 insertions, 0 deletions