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/[email protected] > > > > > > > > ----------------------------------------------------------------- > > > > ---- > > > > ---- > > > > 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/[email protected]/ > > > Hmm, > > Considering > > https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/infiniband/core/umem_dmabuf.c#L192 > > 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/[email protected]/. 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: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > Cc: [email protected] > > > > To: Sumit Semwal <[email protected]> > > > > To: Christian König <[email protected]> > > > > To: Alex Deucher <[email protected]> > > > > To: David Airlie <[email protected]> > > > > To: Simona Vetter <[email protected]> > > > > To: Gerd Hoffmann <[email protected]> > > > > To: Dmitry Osipenko <[email protected]> > > > > To: Gurchetan Singh <[email protected]> > > > > To: Chia-I Wu <[email protected]> > > > > To: Maarten Lankhorst <[email protected]> > > > > To: Maxime Ripard <[email protected]> > > > > To: Thomas Zimmermann <[email protected]> > > > > To: Lucas De Marchi <[email protected]> > > > > To: Thomas Hellström <[email protected]> > > > > To: Rodrigo Vivi <[email protected]> > > > > To: Jason Gunthorpe <[email protected]> > > > > To: Leon Romanovsky <[email protected]> > > > > To: Kevin Tian <[email protected]> > > > > To: Joerg Roedel <[email protected]> > > > > To: Will Deacon <[email protected]> > > > > To: Robin Murphy <[email protected]> > > > > To: Alex Williamson <[email protected]> > > > > > > > > --- > > > > 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 <[email protected]> > > > > > > > >
