linux-kernel - Re: [PATCH v2 2/4] dma-buf: Document revoke semantics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9eba2527-a06e-4f74-a7d6-93f6f91e00e9@amd.com>
Date: Mon, 19 Jan 2026 11:56:16 +0100
From: Christian König <christian.koenig@....com>
To: Leon Romanovsky <leon@...nel.org>, 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>,
 Thomas Hellström <thomas.hellstrom@...ux.intel.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>
Cc: 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 2/4] dma-buf: Document revoke semantics

On 1/18/26 13:08, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@...dia.com>
> 
> Document a DMA-buf revoke mechanism that allows an exporter to explicitly
> invalidate ("kill") a shared buffer after it has been handed out to
> importers. Once revoked, all further CPU and device access is blocked, and
> importers consistently observe failure.
> 
> This requires both importers and exporters to honor the revoke contract.
> 
> For importers, this means implementing .invalidate_mappings() and calling
> dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s support
> for revocation.
> 
> For exporters, this means implementing the .pin() callback, which checks
> the DMA‑buf attachment for a valid revoke implementation.
> 
> Signed-off-by: Leon Romanovsky <leonro@...dia.com>
> ---
>  include/linux/dma-buf.h | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 1b397635c793..e0bc0b7119f5 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -579,6 +579,25 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
>  	return !!dmabuf->ops->pin;
>  }
>  
> +/**
> + * dma_buf_attachment_is_revoke - check if a DMA-buf importer implements
> + * revoke semantics.
> + * @attach: the DMA-buf attachment to check
> + *

> + * Returns true if DMA-buf importer honors revoke semantics, which is
> + * negotiated with the exporter, by making sure that importer implements
> + * .invalidate_mappings() callback and calls to dma_buf_pin() after
> + * DMA-buf attach.

That wording is to unclear. Something like:

Returns true if the DMA-buf importer can handle invalidating it's mappings at any time, even after pinning a buffer.

> + */
> +static inline bool
> +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)

That's clearly not a good name. But that is already discussed in another thread.

> +{
> +	return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) &&

Oh, we should have renamed that as well. Or maybe it is time to completely remove that config option.

> +	       dma_buf_is_dynamic(attach->dmabuf) &&

This is checking exporter and not importer capabilities, please drop.

> +	       (attach->importer_ops &&
> +		attach->importer_ops->invalidate_mappings);

So when invalidate_mappings is implemented we need to be able to call it at any time. Yeah that sounds like a valid approach to me.

But we need to remove the RDNA callback with the warning then to properly signal that. And also please document that in the callback kerneldoc.

Regards,
Christian.

> +}
> +
>  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>  					  struct device *dev);
>  struct dma_buf_attachment *
>