Hi Leon,
On Sat, Jan 24, 2026 at 09:14:18PM +0200, Leon Romanovsky wrote:
From: Leon Romanovsky leonro@nvidia.com
Some exporters need a flow to synchronously revoke access to the DMA-buf by importers. Once revoke is completed the importer is not permitted to touch the memory otherwise they may get IOMMU faults, AERs, or worse.
DMA-buf today defines a revoke flow, for both pinned and dynamic importers, which is broadly:
dma_resv_lock(dmabuf->resv, NULL); // Prevent new mappings from being established priv->revoked = true;
// Tell all importers to eventually unmap dma_buf_invalidate_mappings(dmabuf);
// Wait for any inprogress fences on the old mapping dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_BOOKKEEP, false, MAX_SCHEDULE_TIMEOUT); dma_resv_unlock(dmabuf->resv, NULL);
// Wait for all importers to complete unmap wait_for_completion(&priv->unmapped_comp);
This works well, and an importer that continues to access the DMA-buf after unmapping it is very buggy.
However, the final wait for unmap is effectively unbounded. Several importers do not support invalidate_mappings() at all and won't unmap until userspace triggers it.
This unbounded wait is not suitable for exporters like VFIO and RDMA tha need to issue revoke as part of their normal operations.
Add dma_buf_attach_revocable() to allow exporters to determine the difference between importers that can complete the above in bounded time, and those that can't. It can be called inside the exporter's attach op to reject incompatible importers.
Document these details about how dma_buf_invalidate_mappings() works and what the required sequence is to achieve a full revocation.
Signed-off-by: Leon Romanovsky leonro@nvidia.com
drivers/dma-buf/dma-buf.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 9 +++------ 2 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 1629312d364a..f0e05227bda8 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1242,13 +1242,59 @@ void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach, } EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, "DMA_BUF"); +/**
- dma_buf_attach_revocable - check if a DMA-buf importer implements
- revoke semantics.
- @attach: the DMA-buf attachment to check
- Returns true if the DMA-buf importer can support the revoke sequence
- explained in dma_buf_invalidate_mappings() within bounded time. Meaning the
- importer implements invalidate_mappings() and ensures that unmap is called as
- a result.
- */
+bool dma_buf_attach_revocable(struct dma_buf_attachment *attach) +{
- return attach->importer_ops &&
attach->importer_ops->invalidate_mappings;+} +EXPORT_SYMBOL_NS_GPL(dma_buf_attach_revocable, "DMA_BUF");
I noticed that Patch 5 removes the invalidate_mappings stub from umem_dmabuf.c, effectively making the callback NULL for an RDMA importer. Consequently, dma_buf_attach_revocable() (introduced here) will return false for these importers.
Since the cover letter mentions that VFIO will use dma_buf_attach_revocable() to prevent unbounded waits, this appears to effectively block paths like the VFIO-export -> RDMA-import path..
Given that RDMA is a significant consumer of dma-bufs, are there plans to implement proper revocation support in the IB/RDMA core (umem_dmabuf)?
It would be good to know if there's a plan for bringing such importers into compliance with the new revocation semantics so they can interop with VFIO OR are we completely ruling out users like RDMA / IB importing any DMABUFs exported by VFIO?
Thanks, Praan