kernel.git/drivers/vfio/vfio.c, branch linux-4.12.y

vfio: Remove unnecessary uses of vfio_container.group_lock

2017-07-27T22:10:16Z

commit 7f56c30bd0a232822aca38d288da475613bdff9b upstream. The original intent of vfio_container.group_lock is to protect vfio_container.group_list, however over time it's become a crutch to prevent changes in container composition any time we call into the iommu driver backend. This introduces problems when we start to have more complex interactions, for example when a user's DMA unmap request triggers a notification to an mdev vendor driver, who responds by attempting to unpin mappings within that request, re-entering the iommu backend. We incorrectly assume that the use of read-locks here allow for this nested locking behavior, but a poorly timed write-lock could in fact trigger a deadlock. The current use of group_lock seems to fall into the trap of locking code, not data. Correct that by removing uses of group_lock that are not directly related to group_list. Note that the vfio type1 iommu backend has its own mutex, vfio_iommu.lock, which it uses to protect itself for each of these interfaces anyway. The group_lock appears to be a redundancy for these interfaces and type1 even goes so far as to release its mutex to allow for exactly the re-entrant code path above. Reported-by: Chuanxiao Dong Signed-off-by: Alex Williamson Acked-by: Alexey Kardashevskiy Signed-off-by: Greg Kroah-Hartman

vfio: New external user group/file match

2017-07-27T22:10:16Z

commit 5d6dee80a1e94cc284d03e06d930e60e8d3ecf7d upstream. At the point where the kvm-vfio pseudo device wants to release its vfio group reference, we can't always acquire a new reference to make that happen. The group can be in a state where we wouldn't allow a new reference to be added. This new helper function allows a caller to match a file to a group to facilitate this. Given a file and group, report if they match. Thus the caller needs to already have a group reference to match to the file. This allows the deletion of a group without acquiring a new reference. Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Reviewed-by: Paolo Bonzini Tested-by: Eric Auger Signed-off-by: Greg Kroah-Hartman

vfio: Fix group release deadlock

2017-07-27T22:10:16Z

commit 811642d8d8a82c0cce8dc2debfdaf23c5a144839 upstream. If vfio_iommu_group_notifier() acquires a group reference and that reference becomes the last reference to the group, then vfio_group_put introduces a deadlock code path where we're trying to unregister from the iommu notifier chain from within a callout of that chain. Use a work_struct to release this reference asynchronously. Signed-off-by: Alex Williamson Reviewed-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Greg Kroah-Hartman

vfio: Rework group release notifier warning

2017-03-21T19:19:09Z

The intent of the original warning is make sure that the mdev vendor driver has removed any group notifiers at the point where the group is closed by the user. Theoretically this would be through an orderly shutdown where any devices are release prior to the group release. We can't always count on an orderly shutdown, the user can close the group before the notifier can be removed or the user task might be killed. We'd like to add this sanity test when the group is idle and the only references are from the devices within the group themselves, but we don't have a good way to do that. Instead check both when the group itself is removed and when the group is opened. A bit later than we'd prefer, but better than the current over aggressive approach. Fixes: ccd46dbae77d ("vfio: support notifier chain in vfio_group") Signed-off-by: Alex Williamson Cc: # v4.10 Cc: Jike Song

vfio: fix a typo in comment of function vfio_pin_pages

2017-02-22T18:40:15Z

Correct the description that 'unpinned' -> 'pinned'. Signed-off-by: Changbin Du Signed-off-by: Alex Williamson

vfio: Replace module request with softdep

2017-02-09T19:13:53Z

Rather than doing a module request from within the init function, add a soft dependency on the available IOMMU backend drivers. This makes the dependency visible to userspace when picking modules for the ram disk. Signed-off-by: Alex Williamson

vfio: support notifier chain in vfio_group

2016-12-01T17:40:05Z

Beyond vfio_iommu events, users might also be interested in vfio_group events. For example, if a vfio_group is used along with Qemu/KVM, whenever kvm pointer is set to/cleared from the vfio_group, users could be notified. Currently only VFIO_GROUP_NOTIFY_SET_KVM supported. Cc: Kirti Wankhede Cc: Paolo Bonzini Cc: Xiao Guangrong Signed-off-by: Jike Song [aw: remove use of new typedef] Signed-off-by: Alex Williamson

vfio: vfio_register_notifier: classify iommu notifier

2016-12-01T16:38:47Z

Currently vfio_register_notifier assumes that there is only one notifier chain, which is in vfio_iommu. However, the user might also be interested in events other than vfio_iommu, for example, vfio_group. Refactor vfio_{un}register_notifier implementation to make it feasible. Cc: Paolo Bonzini Cc: Xiao Guangrong Reviewed-by: Kirti Wankhede Signed-off-by: Jike Song [aw: merge with commit 816ca69ea9c7 ("vfio: Fix handling of error returned by 'vfio_group_get_from_dev()'"), remove typedef] Signed-off-by: Alex Williamson

vfio: Fix handling of error returned by 'vfio_group_get_from_dev()'

2016-12-01T15:45:49Z

'vfio_group_get_from_dev()' seems to return only NULL on error, not an error pointer. Fixes: 2169037dc322 ("vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops") Fixes: c086de818dd8 ("vfio iommu: Add blocking notifier to notify DMA_UNMAP") Signed-off-by: Christophe JAILLET Reported-by: Dan Carpenter Signed-off-by: Alex Williamson

vfio: fix vfio_info_cap_add/shift

2016-11-21T18:51:53Z

Capability header next field is an offset relative to the start of the INFO buffer. tmp->next is assigned the proper value but iterations implemented in vfio_info_cap_add and vfio_info_cap_shift use next as an offset between the headers. When coping with multiple capabilities this leads to an Oops. Signed-off-by: Eric Auger Reviewed-by: David Hildenbrand Signed-off-by: Alex Williamson