]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
iommufd: Allow a DMABUF to be revoked
authorJason Gunthorpe <jgg@nvidia.com>
Fri, 21 Nov 2025 15:51:01 +0000 (11:51 -0400)
committerJason Gunthorpe <jgg@nvidia.com>
Tue, 25 Nov 2025 15:30:15 +0000 (11:30 -0400)
commitfc7063abd98e8477c47b792324785ef60c071b9e
tree81c35a90e7d26711f0ebeb8f3ec6b753107dcd81
parent71e2409a0c85c3875ca0dec2515ccceb21a4785b
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>
drivers/iommu/iommufd/io_pagetable.c
drivers/iommu/iommufd/io_pagetable.h
drivers/iommu/iommufd/pages.c