[PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared buffers

[Leon Romanovsky]

This series implements a dma-buf “revoke” mechanism: to allow a dma-buf
exporter to explicitly invalidate (“kill”) a shared buffer after it has
been distributed to importers, so that further CPU and device access is
prevented and importers reliably observe failure.

Today, dma-buf effectively provides “if you have the fd, you can keep using
the memory indefinitely.” That assumption breaks down when an exporter must
reclaim, reset, evict, or otherwise retire backing memory after it has been
shared. Concrete cases include GPU reset and recovery where old allocations
become unsafe to access, memory eviction/overcommit where backing storage
must be withdrawn, and security or isolation situations where continued access
must be prevented. While drivers can sometimes approximate this with
exporter-specific fencing and policy, there is no core dma-buf state transition
that communicates “this buffer is no longer valid; fail access” across all
access paths.

The change in this series is to introduce a core “revoked” state on the dma-buf
object and a corresponding exporter-triggered revoke operation. Once a dma-buf
is revoked, new access paths are blocked so that attempts to DMA-map, vmap, or
mmap the buffer fail in a consistent way.

In addition, the series aims to invalidate existing access as much as the kernel
allows: device mappings are torn down where possible so devices and IOMMUs cannot
continue DMA.

The semantics are intentionally simple: revoke is a one-way, permanent transition
for the lifetime of that dma-buf instance.

>From a compatibility perspective, users that never invoke revoke are unaffected,
and exporters that adopt it gain a core-supported enforcement mechanism rather
than relying on ad hoc driver behavior. The intent is to keep the interface
minimal and avoid imposing policy; the series provides the mechanism to terminate
access, with policy remaining in the exporter and higher-level components.

BTW, see this megathread [1] for additional context.  
Ironically, it was posted exactly one year ago.

[1] https://lore.kernel.org/all/20250107142719.179636-2-yilun.xu@xxxxxxxxxxxxxxx/

Thanks

Cc: linux-rdma@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: linux-media@xxxxxxxxxxxxxxx
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: linaro-mm-sig@xxxxxxxxxxxxxxxx
Cc: kvm@xxxxxxxxxxxxxxx
Cc: iommu@xxxxxxxxxxxxxxx
To: Jason Gunthorpe <jgg@xxxxxxxx>
To: Leon Romanovsky <leon@xxxxxxxxxx>
To: Sumit Semwal <sumit.semwal@xxxxxxxxxx>
To: Christian König <christian.koenig@xxxxxxx>
To: Alex Williamson <alex@xxxxxxxxxxx>
To: Kevin Tian <kevin.tian@xxxxxxxxx>
To: Joerg Roedel <joro@xxxxxxxxxx>
To: Will Deacon <will@xxxxxxxxxx>
To: Robin Murphy <robin.murphy@xxxxxxx>

Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx>
---
Leon Romanovsky (4):
      dma-buf: Introduce revoke semantics
      vfio: Use dma-buf revoke semantics
      iommufd: Require DMABUF revoke semantics
      iommufd/selftest: Reuse dma-buf revoke semantics

 drivers/dma-buf/dma-buf.c          | 36 ++++++++++++++++++++++++++++++++----
 drivers/iommu/iommufd/pages.c      |  2 +-
 drivers/iommu/iommufd/selftest.c   | 12 ++++--------
 drivers/vfio/pci/vfio_pci_dmabuf.c | 27 ++++++---------------------
 include/linux/dma-buf.h            | 31 +++++++++++++++++++++++++++++++
 5 files changed, 74 insertions(+), 34 deletions(-)
---
base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
change-id: 20251221-dmabuf-revoke-b90ef16e4236

Best regards,
--  
Leon Romanovsky <leonro@xxxxxxxxxx>