From: Leon Romanovsky <leonro@nvidia.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@nvidia.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.
+ */
+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);
+}
+
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
 					  struct device *dev);
 struct dma_buf_attachment *

-- 
2.52.0

On Sun, Jan 18, 2026 at 02:08:46PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.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@nvidia.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.
> + */

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.

> +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 ..

Jason

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 <leonro@nvidia.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@nvidia.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.
> > + */
> 
> 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

On 1/18/26 13:08, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.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@nvidia.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 *
> 

On Mon, Jan 19, 2026 at 11:56:16AM +0100, Christian König wrote:
> On 1/18/26 13:08, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.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@nvidia.com>
> > ---
> >  include/linux/dma-buf.h | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)

<...>

> > + * 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.

<...>

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

<...>

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

<...>

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

<...>

> 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.

Will do, thanks

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

On 1/18/26 4:08 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
...
> +/**
> + * 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.
> + */
> +static inline bool
> +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)

Maybe a slight rename, to dma_buf_attachment_is_revocable()?


thanks,
-- 
John Hubbard

On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote:
> On 1/18/26 4:08 AM, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> ...
> > +/**
> > + * 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.
> > + */
> > +static inline bool
> > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
> 
> Maybe a slight rename, to dma_buf_attachment_is_revocable()?

I can do that. The issue is that even "dma_buf_attachment_is_revoke"
is already too long. :)

Thanks

> 
> 
> thanks,
> -- 
> John Hubbard
>

On 1/18/26 11:25 PM, Leon Romanovsky wrote:
> On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote:
>> On 1/18/26 4:08 AM, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@nvidia.com>
>> ...
>>> +/**
>>> + * 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.
>>> + */
>>> +static inline bool
>>> +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
>>
>> Maybe a slight rename, to dma_buf_attachment_is_revocable()?
> 
> I can do that. The issue is that even "dma_buf_attachment_is_revoke"
> is already too long. :)
> 

If you're really pressed for space for some reason, maybe
dma_buf_attach_revocable() ?

Just trying to hang on to the "revocable" part of the name, as
I think it's an improvement.

thanks,
-- 
John Hubbard

On Sun, Jan 18, 2026 at 11:32:20PM -0800, John Hubbard wrote:
> On 1/18/26 11:25 PM, Leon Romanovsky wrote:
> > On Sun, Jan 18, 2026 at 01:40:11PM -0800, John Hubbard wrote:
> > > On 1/18/26 4:08 AM, Leon Romanovsky wrote:
> > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > ...
> > > > +/**
> > > > + * 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.
> > > > + */
> > > > +static inline bool
> > > > +dma_buf_attachment_is_revoke(struct dma_buf_attachment *attach)
> > > 
> > > Maybe a slight rename, to dma_buf_attachment_is_revocable()?
> > 
> > I can do that. The issue is that even "dma_buf_attachment_is_revoke"
> > is already too long. :)
> > 
> 
> If you're really pressed for space for some reason,

Mainly aesthetics.

> maybe dma_buf_attach_revocable() ?
> 
> Just trying to hang on to the "revocable" part of the name, as
> I think it's an improvement.

Sure

> 
> thanks,
> -- 
> John Hubbard
> 
>

On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.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.

See previous comment WRT this.

> 
> 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.

Why would the importer want to verify the exporter's support for
revocation? If the exporter doesn't support it, the only consequence
would be that invalidate_mappings() would never be called, and that
dma_buf_pin() is a NOP. Besides, dma_buf_pin() would not return an
error if the exporter doesn't implement the pin() callback?

Or perhaps I missed a prereq patch?

Thanks,
Thomas

On Sun, Jan 18, 2026 at 03:29:02PM +0100, Thomas Hellström wrote:
> Why would the importer want to verify the exporter's support for
> revocation? If the exporter doesn't support it, the only consequence
> would be that invalidate_mappings() would never be called, and that
> dma_buf_pin() is a NOP. Besides, dma_buf_pin() would not return an
> error if the exporter doesn't implement the pin() callback?

I think the comment and commit message should be clarified that 
dma_buf_attachment_is_revoke() is called by the exporter.

The purpose is for the exporter that wants to call move_notify() on a
pinned DMABUF to determine if the importer is going to support it.

Jason

On Sun, Jan 18, 2026 at 03:29:02PM +0100, Thomas Hellström wrote:
> On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.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.
> 
> See previous comment WRT this.
> 
> > 
> > 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.
> 
> Why would the importer want to verify the exporter's support for
> revocation? If the exporter doesn't support it, the only consequence
> would be that invalidate_mappings() would never be called, and that
> dma_buf_pin() is a NOP. Besides, dma_buf_pin() would not return an
> error if the exporter doesn't implement the pin() callback?

The idea is that both should do revoke and there is a need to indicate
that this exporter has some expectations from the importers. One of them
is that invalidate_mappings exists.

Thanks

> 
> Or perhaps I missed a prereq patch?
> 
> Thanks,
> Thomas
> 
>