Message-ID: <2db90323-9ddc-4408-9074-b44d9178bc68@amd.com>
Date: Mon, 12 Jan 2026 13:57:25 +0100
From: Christian König <christian.koenig@....com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Jason Gunthorpe <jgg@...pe.ca>, Sumit Semwal <sumit.semwal@...aro.org>,
 Alex Williamson <alex@...zbot.org>, Kevin Tian <kevin.tian@...el.com>,
 Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
 Robin Murphy <robin.murphy@....com>, linux-rdma@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
 kvm@...r.kernel.org, iommu@...ts.linux.dev
Subject: Re: [PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared
 buffers

On 1/12/26 13:19, Leon Romanovsky wrote:
> On Mon, Jan 12, 2026 at 11:04:38AM +0100, Christian König wrote:
>> On 1/11/26 11:37, Leon Romanovsky wrote:
>>> This series implements 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.
>>
>> We already have that. This is what the move_notify is all about.
>>
>>> Today, dma-buf effectively provides “if you have the fd, you can keep using
>>> the memory indefinitely.” That assumption breaks down when an exporter must
>>> reclaim, reset, evict, or otherwise retire backing memory after it has been
>>> shared. Concrete cases include GPU reset and recovery where old allocations
>>> become unsafe to access, memory eviction/overcommit where backing storage
>>> must be withdrawn, and security or isolation situations where continued access
>>> must be prevented. While drivers can sometimes approximate this with
>>> exporter-specific fencing and policy, there is no core dma-buf state transition
>>> that communicates “this buffer is no longer valid; fail access” across all
>>> access paths.
>>
>> It's not correct that there is no DMA-buf handling for this use case.
>>
>>> The change in this series is to introduce a 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.
>>>
>>> In addition, the series aims to invalidate existing access as much as the kernel
>>> allows: device mappings are torn down where possible so devices and IOMMUs cannot
>>> continue DMA.
>>>
>>> The semantics are intentionally simple: revoke is a one-way, permanent transition
>>> for the lifetime of that dma-buf instance.
>>>
>>> From a compatibility perspective, users that never invoke revoke are unaffected,
>>> and exporters that adopt it gain a core-supported enforcement mechanism rather
>>> than relying on ad hoc driver behavior. The intent is to keep the interface
>>> minimal and avoid imposing policy; the series provides the mechanism to terminate
>>> access, with policy remaining in the exporter and higher-level components.
>>
>> As far as I can see that patch set is completely superfluous.
>>
>> The move_notify mechanism has been implemented exactly to cover this use case and is in use for a couple of years now.
>>
>> What exactly is missing?
> 
> From what I can tell, the missing piece is what happens after .move_notify()
> is called. According to the documentation, the exporter remains valid, and
> the importer is expected to recreate all mappings.
> 
> include/linux/dma-buf.h:
>   471          * Mappings stay valid and are not directly affected by this callback.
>   472          * But the DMA-buf can now be in a different physical location, so all
>   473          * mappings should be destroyed and re-created as soon as possible.
>   474          *
>   475          * New mappings can be created after this callback returns, and will
>   476          * point to the new location of the DMA-buf.
> 
> Call to dma_buf_move_notify() does not prevent new attachments to that
> exporter, while "revoke" does. In the current code, the importer is not aware
> that the exporter no longer exists and will continue calling
> dma_buf_map_attachment().

Yeah and that is perfectly intentional.

> In summary, the current implementation allows a single .attach() check but
> permits multiple .map_dma_buf() calls. With "revoke", we gain the ability to
> block any subsequent .map_dma_buf() operations.

Clear NAK to that plan. This is not something DMA-buf should need to deal with and as far as I can see is incompatible with the UAPI.

If a DMA-buf can no longer be attached or mapped then the relevant callbacks just need to return an error code.

Existing mappings can be invalidated with the move_notify callback and that functionality should be sufficient to prevent importers from accessing the backing store.

Existing attachments should stay around until the importer drops their usage.

In other words the exporter can't force an importer to drop their attachments, that would be a violation of the UAPI.

Regards,
Christian.

> 
> Main use case is VFIO as exporter and IOMMUFD as importer.
> 
> Thanks
> 
>>
>> Regards,
>> Christian.
>>
>>>
>>> BTW, see this megathread [1] for additional context.  
>>> Ironically, it was posted exactly one year ago.
>>>
>>> [1] https://lore.kernel.org/all/20250107142719.179636-2-yilun.xu@linux.intel.com/
>>>
>>> Thanks
>>>
>>> Cc: linux-rdma@...r.kernel.org
>>> Cc: linux-kernel@...r.kernel.org
>>> Cc: linux-media@...r.kernel.org
>>> Cc: dri-devel@...ts.freedesktop.org
>>> Cc: linaro-mm-sig@...ts.linaro.org
>>> Cc: kvm@...r.kernel.org
>>> Cc: iommu@...ts.linux.dev
>>> To: Jason Gunthorpe <jgg@...pe.ca>
>>> To: Leon Romanovsky <leon@...nel.org>
>>> To: Sumit Semwal <sumit.semwal@...aro.org>
>>> To: Christian König <christian.koenig@....com>
>>> To: Alex Williamson <alex@...zbot.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>
>>>
>>> Signed-off-by: Leon Romanovsky <leonro@...dia.com>
>>> ---
>>> Leon Romanovsky (4):
>>>       dma-buf: Introduce revoke semantics
>>>       vfio: Use dma-buf revoke semantics
>>>       iommufd: Require DMABUF revoke semantics
>>>       iommufd/selftest: Reuse dma-buf revoke semantics
>>>
>>>  drivers/dma-buf/dma-buf.c          | 36 ++++++++++++++++++++++++++++++++----
>>>  drivers/iommu/iommufd/pages.c      |  2 +-
>>>  drivers/iommu/iommufd/selftest.c   | 12 ++++--------
>>>  drivers/vfio/pci/vfio_pci_dmabuf.c | 27 ++++++---------------------
>>>  include/linux/dma-buf.h            | 31 +++++++++++++++++++++++++++++++
>>>  5 files changed, 74 insertions(+), 34 deletions(-)
>>> ---
>>> base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb
>>> change-id: 20251221-dmabuf-revoke-b90ef16e4236
>>>
>>> Best regards,
>>> --  
>>> Leon Romanovsky <leonro@...dia.com>
>>>
>>
>>

Powered by blists - more mailing lists