aboutsummaryrefslogtreecommitdiff
path: root/include/uapi/linux/vfio.h
diff options
context:
space:
mode:
authorAlex Williamson <alex.williamson@redhat.com>2015-06-09 10:08:57 -0600
committerAlex Shi <alex.shi@linaro.org>2016-04-27 21:53:11 +0800
commitce6482d1629c021569cedb1002faff0a0a1c4a10 (patch)
tree834d6808252bb697e5ef07a44b86e3a1b3eb2609 /include/uapi/linux/vfio.h
parent4e3e10471bea4dbe8cbc49dd8eb007557e90c0c9 (diff)
vfio/pci: Fix racy vfio_device_get_from_dev() call
Testing the driver for a PCI device is racy, it can be all but complete in the release path and still report the driver as ours. Therefore we can't trust drvdata to be valid. This race can sometimes be seen when one port of a multifunction device is being unbound from the vfio-pci driver while another function is being released by the user and attempting a bus reset. The device in the remove path is found as a dependent device for the bus reset of the release path device, the driver is still set to vfio-pci, but the drvdata has already been cleared, resulting in a null pointer dereference. To resolve this, fix vfio_device_get_from_dev() to not take the dev_get_drvdata() shortcut and instead traverse through the iommu_group, vfio_group, vfio_device path to get a reference we can trust. Once we have that reference, we know the device isn't in transition and we can test to make sure the driver is still what we expect, so that we don't interfere with devices we don't own. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> (cherry picked from commit 20f300175a1e150dae231e21dfa1fc4c6fcf4db6) Signed-off-by: Alex Shi <alex.shi@linaro.org>
Diffstat (limited to 'include/uapi/linux/vfio.h')
0 files changed, 0 insertions, 0 deletions