diff options
author | Alex Williamson <alex.williamson@redhat.com> | 2017-07-08 00:37:38 +0300 |
---|---|---|
committer | Alex Williamson <alex.williamson@redhat.com> | 2017-07-08 00:37:38 +0300 |
commit | 7f56c30bd0a232822aca38d288da475613bdff9b (patch) | |
tree | de4ef02762b2c79b6801778defdea587718eeb89 /virt | |
parent | 5d6dee80a1e94cc284d03e06d930e60e8d3ecf7d (diff) | |
download | linux-7f56c30bd0a232822aca38d288da475613bdff9b.tar.xz |
vfio: Remove unnecessary uses of vfio_container.group_lock
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 <chuanxiao.dong@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: stable@vger.kernel.org # v4.10+
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions