On 1/11/26 11:37, Leon Romanovsky wrote: > 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.
We already have that. This is what the move_notify is all about. > 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. It's not correct that there is no DMA-buf handling for this use case. > 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. As far as I can see that patch set is completely superfluous. The move_notify mechanism has been implemented exactly to cover this use case and is in use for a couple of years now. What exactly is missing? Regards, Christian. > > BTW, see this megathread [1] for additional context. > Ironically, it was posted exactly one year ago. > > [1] > https://lore.kernel.org/all/[email protected]/ > > Thanks > > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > To: Jason Gunthorpe <[email protected]> > To: Leon Romanovsky <[email protected]> > To: Sumit Semwal <[email protected]> > To: Christian König <[email protected]> > To: Alex Williamson <[email protected]> > To: Kevin Tian <[email protected]> > To: Joerg Roedel <[email protected]> > To: Will Deacon <[email protected]> > To: Robin Murphy <[email protected]> > > Signed-off-by: Leon Romanovsky <[email protected]> > --- > 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 <[email protected]> >
