On Mon, Jan 19, 2026 at 11:20:46AM +0100, Christian König wrote: > On 1/19/26 10:27, 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. > > Please don't document that. This is specific exporter behavior and doesn't > belong into DMA-buf at all. > > >> 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. > > I have to clearly reject that. > > It's the job of the exporter to reject such calls with an appropriate error > and not the importer to not make them.
Current code behaves as expected: the exporter rejects mapping attempts after .invalidate_mapping is called, and handles the logic internally. However, it is not clear what exactly you are proposing. In v1 — which you objected to — I suggested negotiating revoke support along with the logic for rejecting mappings in the dma-buf core. In this version, you object to placing the rejection logic in the 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 > > Yes, that case is well known. > > > this sounds like it's not just undocumented but also in some cases > > unimplemented. The xe driver for one doesn't expect move_notify() to be > > called on pinned buffers, > > And that is what we need to change. See move_notify can happen on pinned > buffers currently as well. > > For example in the case of PCI hot unplug. After pinning we just don't call > it for memory management needs any more. > > We just haven't documented that properly. > > > 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? > > That's what this patch set here should do, yes. > > Regards, > Christian. > > > > > 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]> > >>>> > >>> > > >
