On Mon, Jan 19, 2026 at 12:44:21PM -0400, Jason Gunthorpe wrote:
> On Sun, Jan 18, 2026 at 02:08:46PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > 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.
> > + */
>
> I think this clarification should also have comment to
> dma_buf_move_notify(). Maybe like this:
>
> @@ -1324,7 +1324,18 @@
> EXPORT_SYMBOL_NS_GPL(dma_buf_sgt_unmap_attachment_unlocked, "DMA_BUF");
> * @dmabuf: [in] buffer which is moving
> *
> * Informs all attachments that they need to destroy and recreate all their
> - * mappings.
> + * mappings. If the attachment is dynamic then the dynamic importer is
> expected
> + * to invalidate any caches it has of the mapping result and perform a new
> + * mapping request before allowing HW to do any further DMA.
> + *
> + * If the attachment is pinned then this informs the pinned importer that
> + * the underlying mapping is no longer available. Pinned importers may take
> + * this is as a permanent revocation so exporters should not trigger it
> + * lightly.
> + *
> + * For legacy pinned importers that cannot support invalidation this is a
> NOP.
> + * Drivers can call dma_buf_attachment_is_revoke() to determine if the
> + * importer supports this.
> */
>
> Also it would be nice to document what Christian pointed out regarding
> fences after move_notify.
I added this comment too:
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 6dd70f7b992d..478127dc63e9 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1253,6 +1253,10 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked,
"DMA_BUF");
* For legacy pinned importers that cannot support invalidation this is a NOP.
* Drivers can call dma_buf_attach_revocable() to determine if the importer
* supports this.
+ *
+ * NOTE: The invalidation triggers asynchronous HW operation and the callers
+ * need to wait for this operation to complete by calling
+ * to dma_resv_wait_timeout().
*/
void dma_buf_move_notify(struct dma_buf *dmabuf)
{
>
> > +static inline bool
> > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
> > +{
> > + return IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY) &&
> > + dma_buf_is_dynamic(attach->dmabuf) &&
> > + (attach->importer_ops &&
> > + attach->importer_ops->invalidate_mappings);
> > +}
>
> And I don't think we should use a NULL invalidate_mappings function
> pointer to signal this.
>
> It sounds like the direction is to require importers to support
> move_notify, so we should not make it easy to just drop a NULL in the
> ops struct to get out of the desired configuration.
>
> I suggest defining a function
> "dma_buf_unsupported_invalidate_mappings" and use
> EXPORT_SYMBOL_FOR_MODULES so only RDMA can use it. Then check for that
> along with NULL importer_ops to cover the two cases where it is not
> allowed.
>
> The only reason RDMA has to use dma_buf_dynamic_attach() is to set the
> allow_p2p=true ..
Will do.
>
> Jason
