On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote:
On Mon, 2026-01-19 at 09:52 +0200, Leon Romanovsky wrote:
On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote:
Hi, Leon,
On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
Changelog: v2: * Changed series to document the revoke semantics instead of implementing it. v1: https://patch.msgid.link/20260111-dmabuf-revoke-v1-0-fb4bcc8c259b@nvidia.com
This series documents 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.
The change in this series is to properly document and use existing 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.
This sounds like it does not match how many GPU-drivers use the move_notify() callback.
No change for them.
move_notify() would typically invalidate any device maps and any asynchronous part of that invalidation would be complete when the dma- buf's reservation object becomes idle WRT DMA_RESV_USAGE_BOOKKEEP fences.
This part has not changed and remains the same for the revocation flow as well.
However, the importer could, after obtaining the resv lock, obtain a new map using dma_buf_map_attachment(), and I'd assume the CPU maps work in the same way, I.E. move_notify() does not *permanently* revoke importer access.
This part diverges by design and is documented to match revoke semantics. It defines what must occur after the exporter requests that the buffer be "killed". An importer that follows revoke semantics will not attempt to call dma_buf_map_attachment(), and the exporter will block any remapping attempts regardless. See the priv->revoked flag in the VFIO exporter.
In addition, in this email thread, Christian explains that revoke semantics already exists, with the combination of dma_buf_pin and dma_buf_move_notify, just not documented: https://lore.kernel.org/all/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/
Hmm,
Considering
https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/um...
this sounds like it's not just undocumented but also in some cases unimplemented.
Yes, it was discussed later in the thread https://lore.kernel.org/all/20260112153503.GF745888@ziepe.ca/. RDMA will need some adjustments later, but first we need to document the existing semantics.
The xe driver for one doesn't expect move_notify() to be called on pinned buffers, so if that is indeed going to be part of the dma-buf protocol, wouldn't support for that need to be advertised by the importer?
This is what Jason proposed with "enum dma_buf_move_notify_level", but for some reason we got no responses.
Thanks
Thanks, Thomas
Thanks
/Thomas
Thanks
Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-kernel@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: virtualization@lists.linux.dev Cc: intel-xe@lists.freedesktop.org Cc: linux-rdma@vger.kernel.org Cc: iommu@lists.linux.dev Cc: kvm@vger.kernel.org To: Sumit Semwal sumit.semwal@linaro.org To: Christian König christian.koenig@amd.com To: Alex Deucher alexander.deucher@amd.com To: David Airlie airlied@gmail.com To: Simona Vetter simona@ffwll.ch To: Gerd Hoffmann kraxel@redhat.com To: Dmitry Osipenko dmitry.osipenko@collabora.com To: Gurchetan Singh gurchetansingh@chromium.org To: Chia-I Wu olvaffe@gmail.com To: Maarten Lankhorst maarten.lankhorst@linux.intel.com To: Maxime Ripard mripard@kernel.org To: Thomas Zimmermann tzimmermann@suse.de To: Lucas De Marchi lucas.demarchi@intel.com To: Thomas Hellström thomas.hellstrom@linux.intel.com To: Rodrigo Vivi rodrigo.vivi@intel.com To: Jason Gunthorpe jgg@ziepe.ca To: Leon Romanovsky leon@kernel.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 To: Alex Williamson alex@shazbot.org
Leon Romanovsky (4): dma-buf: Rename .move_notify() callback to a clearer identifier dma-buf: Document revoke semantics iommufd: Require DMABUF revoke semantics vfio: Add pinned interface to perform revoke semantics
drivers/dma-buf/dma-buf.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++-- drivers/gpu/drm/virtio/virtgpu_prime.c | 2 +- drivers/gpu/drm/xe/tests/xe_dma_buf.c | 6 +++--- drivers/gpu/drm/xe/xe_dma_buf.c | 2 +- drivers/infiniband/core/umem_dmabuf.c | 4 ++-- drivers/infiniband/hw/mlx5/mr.c | 2 +- drivers/iommu/iommufd/pages.c | 11 +++++++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 16 ++++++++++++++++ include/linux/dma-buf.h | 25 ++++++++++++++++++++++--- 10 files changed, 60 insertions(+), 18 deletions(-)
base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb change-id: 20251221-dmabuf-revoke-b90ef16e4236
Best regards, -- Leon Romanovsky leonro@nvidia.com