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

["Christian König" <christian.koenig@amd.com>]

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/20250107142719.179636-2-yilun.xu@linux.intel.com/
> 
> Thanks
> 
> Cc: linux-rdma@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-media@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-sig@lists.linaro.org
> Cc: kvm@vger.kernel.org
> Cc: iommu@lists.linux.dev
> To: Jason Gunthorpe <jgg@ziepe.ca>
> To: Leon Romanovsky <leon@kernel.org>
> To: Sumit Semwal <sumit.semwal@linaro.org>
> To: Christian König <christian.koenig@amd.com>
> To: Alex Williamson <alex@shazbot.org>
> To: Kevin Tian <kevin.tian@intel.com>
> To: Joerg Roedel <joro@8bytes.org>
> To: Will Deacon <will@kernel.org>
> To: Robin Murphy <robin.murphy@arm.com>
> 
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> 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@nvidia.com>
>