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(-)
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.
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>
On Sun, Jan 18, 2026 at 02:08:44PM +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. I think it would help to explain the bigger picture in the cover letter: DMABUF has quietly allowed calling move_notify on pinned DMABUFs, even though legacy importers using dma_buf_attach() would simply ignore these calls. RDMA saw this and needed to use allow_peer2peer=true, so implemented a new-style pinned importer with an explicitly non-working move_notify() callback. This has been tolerable because the existing exporters are thought to only call move_notify() on a pinned DMABUF under RAS events and we have been willing to tolerate the UAF that results by allowing the importer to continue to use the mapping in this rare case. VFIO wants to implement a pin supporting exporter that will issue a revoking move_notify() around FLRs and a few other user triggerable operations. Since this is much more common we are not willing to tolerate the security UAF caused by interworking with non-move_notify() supporting drivers. Thus till now VFIO has required dynamic importers, even though it never actually moves the buffer location. To allow VFIO to work with pinned importers, according to how DMABUF was intended, we need to allow VFIO to detect if an importer is legacy or RDMA and does not actually implement move_notify(). Introduce a new function that exporters can call to detect these less capable importers. VFIO can then refuse to accept them during attach. In theory all exporters that call move_notify() on pinned DMABUF's should call this function, however that would break a number of widely used NIC/GPU flows. Thus for now do not spread this further than VFIO until we can understand how much of RDMA can implement the full semantic. In the process clarify how move_notify is intended to be used with pinned DMABUFs. Jason
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. 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. 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. /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> >
On Sun, Jan 18, 2026 at 03:16:25PM +0100, Thomas Hellström wrote: > > 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. > > 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. > > 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. I think this was explained a bit in this thread, but I wanted to repeat the explanation to be really clear.. If the attachment is not pinned than calling move_notify() is as you say. The importer should expect multiple move_notify() calls and handle all of them. The exporter can move the location around and make it revoked/unrevoked at will. If it is revoked then dma_buf_map_attachment() fails, the importer could cache this and fail DMAs until the next move_notify(). If the attachment is *pinned* then we propose to allow the importer to revoke only and not require restoration. IOW a later move_notify() that signals a previously failing dma_buf_map_attachment() is no longer failing can be igmored by a pinned importer. This at least matches what iommufd is able to do right now. IOW, calling move_notify() on a pinned DMABUF is a special operationg we are calling "revoke" and means that the exporter accepts that the mapping is potentially gone from pinned importers forever. ie don't use it lightly. Jason
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/ 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> > > >
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/umem_dmabuf.c#L192 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, 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? 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> > > > > >
On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote: > 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, 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? Can you clarify this? I don't see xe's importer calling dma_buf_pin() or dma_buf_attach() outside of tests? It's importer implements a fully functional looking dynamic attach with move_notify()? I see the exporer is checking for pinned and then not calling move_notify - is that what you mean? When I looked through all the importers only RDMA obviously didn't support move_notify on pinned buffers. Jason
On Mon, 2026-01-19 at 12:24 -0400, Jason Gunthorpe wrote: > On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote: > > 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, 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? > > Can you clarify this? > > I don't see xe's importer calling dma_buf_pin() or dma_buf_attach() > outside of tests? It's importer implements a fully functional looking > dynamic attach with move_notify()? > > I see the exporer is checking for pinned and then not calling > move_notify - is that what you mean? No it was if move_notify() is called on a pinned buffer, things will probably blow up. And I was under the impression that we'd might be pinning imported framebuffers but either we don't get any of those or we're using the incorrect interface to pin, so it might not be a big issue from the xe side. Need to check this. In any case we'd want to support revoking also of pinned buffers moving forward, so question really becomes whether in the mean-time we need to flag somehow that we don't support it. Thanks, Thomas > > When I looked through all the importers only RDMA obviously didn't > support move_notify on pinned buffers. > > Jason
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/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. 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. >> 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/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: 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> >>>> >>> >
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/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. > > 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/f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com/ > > > > > > 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: 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> > >>>> > >>> > > >
On 1/19/26 11:53, Leon Romanovsky wrote: > 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/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. >> >> 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. Sorry I probably wasn't explaining this correctly. I was rejecting the idea of doing this in the framework, e.g. the middle layer, or that importers would be force to drop their references. That an exporter rejects attempts to attach or map a resource is perfectly valid. Regards, Christian. > >> >>>> 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/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: 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> >>>>>> >>>>> >>> >>
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/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/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> > > > > > > > >
© 2016 - 2026 Red Hat, Inc.