diff options
| author | Jason Gunthorpe <jgg@nvidia.com> | 2025-11-21 11:51:01 -0400 |
|---|---|---|
| committer | Jason Gunthorpe <jgg@nvidia.com> | 2025-11-25 11:30:15 -0400 |
| commit | fc7063abd98e8477c47b792324785ef60c071b9e (patch) | |
| tree | 81c35a90e7d26711f0ebeb8f3ec6b753107dcd81 /rust/helpers/helpers.c | |
| parent | 71e2409a0c85c3875ca0dec2515ccceb21a4785b (diff) | |
iommufd: Allow a DMABUF to be revoked
When connected to VFIO, the only DMABUF exporter that is accepted, the
move_notify callback will be made when VFIO wants to remove access to the
MMIO. This is being called revoke.
Wire up revoke to go through all the iommu_domain's that have mapped the
DMABUF and unmap them.
The locking here is unpleasant, since the existing locking scheme was
designed to come from the iopt through the area to the pages we cannot use
pages as starting point for the locking. There is no way to obtain the
domains_rwsem before obtaining the pages mutex to reliably use the
existing domains_itree.
Solve this problem by adding a new tracking structure just for DMABUF
revoke. Record a linked list of areas and domains inside the pages
mutex. Clean the entries on the list during revoke. The map/unmaps are now
all done under a pages mutex while updating the tracking linked list so
nothing can get out of sync. Only one lock is required for revoke
processing.
Link: https://patch.msgid.link/r/4-v2-b2c110338e3f+5c2-iommufd_dmabuf_jgg@nvidia.com
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Diffstat (limited to 'rust/helpers/helpers.c')
0 files changed, 0 insertions, 0 deletions
