Message-ID: <30ec9e80-f5a8-4b30-a55a-965f20f62125@amd.com>
Date: Mon, 19 Jan 2026 13:05:26 +0100
From: Christian König <christian.koenig@....com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
 Sumit Semwal <sumit.semwal@...aro.org>,
 Alex Deucher <alexander.deucher@....com>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Gerd Hoffmann <kraxel@...hat.com>,
 Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 Gurchetan Singh <gurchetansingh@...omium.org>, Chia-I Wu
 <olvaffe@...il.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Lucas De Marchi <lucas.demarchi@...el.com>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Jason Gunthorpe <jgg@...pe.ca>,
 Kevin Tian <kevin.tian@...el.com>, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
 Alex Williamson <alex@...zbot.org>, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
 linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
 virtualization@...ts.linux.dev, intel-xe@...ts.freedesktop.org,
 linux-rdma@...r.kernel.org, iommu@...ts.linux.dev, kvm@...r.kernel.org
Subject: Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate
 shared buffers

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@...r.kernel.org
>>>>>> Cc: dri-devel@...ts.freedesktop.org
>>>>>> Cc: linaro-mm-sig@...ts.linaro.org
>>>>>> Cc: linux-kernel@...r.kernel.org
>>>>>> Cc: amd-gfx@...ts.freedesktop.org
>>>>>> Cc: virtualization@...ts.linux.dev
>>>>>> Cc: intel-xe@...ts.freedesktop.org
>>>>>> Cc: linux-rdma@...r.kernel.org
>>>>>> Cc: iommu@...ts.linux.dev
>>>>>> Cc: kvm@...r.kernel.org
>>>>>> To: Sumit Semwal <sumit.semwal@...aro.org>
>>>>>> To: Christian König <christian.koenig@....com>
>>>>>> To: Alex Deucher <alexander.deucher@....com>
>>>>>> To: David Airlie <airlied@...il.com>
>>>>>> To: Simona Vetter <simona@...ll.ch>
>>>>>> To: Gerd Hoffmann <kraxel@...hat.com>
>>>>>> To: Dmitry Osipenko <dmitry.osipenko@...labora.com>
>>>>>> To: Gurchetan Singh <gurchetansingh@...omium.org>
>>>>>> To: Chia-I Wu <olvaffe@...il.com>
>>>>>> To: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
>>>>>> To: Maxime Ripard <mripard@...nel.org>
>>>>>> To: Thomas Zimmermann <tzimmermann@...e.de>
>>>>>> To: Lucas De Marchi <lucas.demarchi@...el.com>
>>>>>> To: Thomas Hellström <thomas.hellstrom@...ux.intel.com>
>>>>>> To: Rodrigo Vivi <rodrigo.vivi@...el.com>
>>>>>> To: Jason Gunthorpe <jgg@...pe.ca>
>>>>>> To: Leon Romanovsky <leon@...nel.org>
>>>>>> To: Kevin Tian <kevin.tian@...el.com>
>>>>>> To: Joerg Roedel <joro@...tes.org>
>>>>>> To: Will Deacon <will@...nel.org>
>>>>>> To: Robin Murphy <robin.murphy@....com>
>>>>>> To: Alex Williamson <alex@...zbot.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@...dia.com>
>>>>>>
>>>>>
>>>
>>

Powered by blists - more mailing lists