From: Leon Romanovsky <leonro@nvidia.com>

The .invalidate_mapping() callback is documented as optional, yet it
effectively became mandatory whenever importer_ops were provided. This
led to cases where RDMA non-ODP code had to supply an empty stub just to
provide allow_peer2peer.

Document this behavior by creating a dedicated export for the
dma_buf_unsupported_invalidate_mappings() function. This function is
intended solely for the RDMA non-ODP case and must not be used by any
other dma-buf importer.

This makes it possible to rely on a valid .invalidate_mappings()
callback to determine whether an importer supports revocation.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
 drivers/dma-buf/dma-buf.c             | 14 ++++++++++++++
 drivers/infiniband/core/umem_dmabuf.c | 11 +----------
 include/linux/dma-buf.h               |  4 +++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index cd3b60ce4863..c4fa35034b92 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1238,6 +1238,20 @@ void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, "DMA_BUF");
 
+/*
+ * This function shouldn't be used by anyone except RDMA non-ODP case.
+ * The reason to it is UAPI mistake where dma-buf was exported to the
+ * userspace without knowing that .invalidate_mappings() can be called
+ * for pinned memory too.
+ *
+ * This warning shouldn't be seen in real production scenario.
+ */
+void dma_buf_unsupported_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+	pr_warn("Invalidate callback should not be called when memory is pinned\n");
+}
+EXPORT_SYMBOL_FOR_MODULES(dma_buf_unsupported_invalidate_mappings, "ib_uverbs");
+
 /**
  * dma_buf_move_notify - notify attachments that DMA-buf is moving
  *
diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
index d77a739cfe7a..81442a887b48 100644
--- a/drivers/infiniband/core/umem_dmabuf.c
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -184,18 +184,9 @@ struct ib_umem_dmabuf *ib_umem_dmabuf_get(struct ib_device *device,
 }
 EXPORT_SYMBOL(ib_umem_dmabuf_get);
 
-static void
-ib_umem_dmabuf_unsupported_move_notify(struct dma_buf_attachment *attach)
-{
-	struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
-
-	ibdev_warn_ratelimited(umem_dmabuf->umem.ibdev,
-			       "Invalidate callback should not be called when memory is pinned\n");
-}
-
 static struct dma_buf_attach_ops ib_umem_dmabuf_attach_pinned_ops = {
 	.allow_peer2peer = true,
-	.invalidate_mappings = ib_umem_dmabuf_unsupported_move_notify,
+	.invalidate_mappings = dma_buf_unsupported_invalidate_mappings,
 };
 
 struct ib_umem_dmabuf *
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 1b397635c793..7d7d0a4fb762 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -458,7 +458,7 @@ struct dma_buf_attach_ops {
 	bool allow_peer2peer;
 
 	/**
-	 * @invalidate_mappings: [optional] notification that the DMA-buf is moving
+	 * @invalidate_mappings: notification that the DMA-buf is moving
 	 *
 	 * If this callback is provided the framework can avoid pinning the
 	 * backing store while mappings exists.
@@ -601,6 +601,8 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
 void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
 				enum dma_data_direction);
 void dma_buf_move_notify(struct dma_buf *dma_buf);
+void dma_buf_unsupported_invalidate_mappings(struct dma_buf_attachment *attach);
+
 int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
 			     enum dma_data_direction dir);
 int dma_buf_end_cpu_access(struct dma_buf *dma_buf,

-- 
2.52.0

On 1/20/26 15:07, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> The .invalidate_mapping() callback is documented as optional, yet it
> effectively became mandatory whenever importer_ops were provided. This
> led to cases where RDMA non-ODP code had to supply an empty stub just to
> provide allow_peer2peer.
> 
> Document this behavior by creating a dedicated export for the
> dma_buf_unsupported_invalidate_mappings() function. This function is
> intended solely for the RDMA non-ODP case and must not be used by any
> other dma-buf importer.
> 
> This makes it possible to rely on a valid .invalidate_mappings()
> callback to determine whether an importer supports revocation.
> 
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> ---
>  drivers/dma-buf/dma-buf.c             | 14 ++++++++++++++
>  drivers/infiniband/core/umem_dmabuf.c | 11 +----------
>  include/linux/dma-buf.h               |  4 +++-
>  3 files changed, 18 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index cd3b60ce4863..c4fa35034b92 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1238,6 +1238,20 @@ void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
>  }
>  EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, "DMA_BUF");
>  
> +/*
> + * This function shouldn't be used by anyone except RDMA non-ODP case.
> + * The reason to it is UAPI mistake where dma-buf was exported to the
> + * userspace without knowing that .invalidate_mappings() can be called
> + * for pinned memory too.
> + *
> + * This warning shouldn't be seen in real production scenario.
> + */
> +void dma_buf_unsupported_invalidate_mappings(struct dma_buf_attachment *attach)
> +{
> +	pr_warn("Invalidate callback should not be called when memory is pinned\n");
> +}
> +EXPORT_SYMBOL_FOR_MODULES(dma_buf_unsupported_invalidate_mappings, "ib_uverbs");
> +

Well that is exactly the opposite of what I had in mind.

The RDMA non-ODP case should explicitly not provide an invalidate_mappings callback, but only the dma_buf_attach_ops with allow_peer2peer set to true.

This is done to explicitly note that RDMA non-ODP can't do invalidation's.

Regards,
Christian.

>  /**
>   * dma_buf_move_notify - notify attachments that DMA-buf is moving
>   *
> diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
> index d77a739cfe7a..81442a887b48 100644
> --- a/drivers/infiniband/core/umem_dmabuf.c
> +++ b/drivers/infiniband/core/umem_dmabuf.c
> @@ -184,18 +184,9 @@ struct ib_umem_dmabuf *ib_umem_dmabuf_get(struct ib_device *device,
>  }
>  EXPORT_SYMBOL(ib_umem_dmabuf_get);
>  
> -static void
> -ib_umem_dmabuf_unsupported_move_notify(struct dma_buf_attachment *attach)
> -{
> -	struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
> -
> -	ibdev_warn_ratelimited(umem_dmabuf->umem.ibdev,
> -			       "Invalidate callback should not be called when memory is pinned\n");
> -}
> -
>  static struct dma_buf_attach_ops ib_umem_dmabuf_attach_pinned_ops = {
>  	.allow_peer2peer = true,
> -	.invalidate_mappings = ib_umem_dmabuf_unsupported_move_notify,
> +	.invalidate_mappings = dma_buf_unsupported_invalidate_mappings,
>  };
>  
>  struct ib_umem_dmabuf *
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 1b397635c793..7d7d0a4fb762 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -458,7 +458,7 @@ struct dma_buf_attach_ops {
>  	bool allow_peer2peer;
>  
>  	/**
> -	 * @invalidate_mappings: [optional] notification that the DMA-buf is moving
> +	 * @invalidate_mappings: notification that the DMA-buf is moving
>  	 *
>  	 * If this callback is provided the framework can avoid pinning the
>  	 * backing store while mappings exists.
> @@ -601,6 +601,8 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
>  void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
>  				enum dma_data_direction);
>  void dma_buf_move_notify(struct dma_buf *dma_buf);
> +void dma_buf_unsupported_invalidate_mappings(struct dma_buf_attachment *attach);
> +
>  int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
>  			     enum dma_data_direction dir);
>  int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
>

On Wed, Jan 21, 2026 at 09:59:59AM +0100, Christian König wrote:
> On 1/20/26 15:07, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > The .invalidate_mapping() callback is documented as optional, yet it
> > effectively became mandatory whenever importer_ops were provided. This
> > led to cases where RDMA non-ODP code had to supply an empty stub just to
> > provide allow_peer2peer.
> > 
> > Document this behavior by creating a dedicated export for the
> > dma_buf_unsupported_invalidate_mappings() function. This function is
> > intended solely for the RDMA non-ODP case and must not be used by any
> > other dma-buf importer.
> > 
> > This makes it possible to rely on a valid .invalidate_mappings()
> > callback to determine whether an importer supports revocation.
> > 
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> >  drivers/dma-buf/dma-buf.c             | 14 ++++++++++++++
> >  drivers/infiniband/core/umem_dmabuf.c | 11 +----------
> >  include/linux/dma-buf.h               |  4 +++-
> >  3 files changed, 18 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index cd3b60ce4863..c4fa35034b92 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -1238,6 +1238,20 @@ void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
> >  }
> >  EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, "DMA_BUF");
> >  
> > +/*
> > + * This function shouldn't be used by anyone except RDMA non-ODP case.
> > + * The reason to it is UAPI mistake where dma-buf was exported to the
> > + * userspace without knowing that .invalidate_mappings() can be called
> > + * for pinned memory too.
> > + *
> > + * This warning shouldn't be seen in real production scenario.
> > + */
> > +void dma_buf_unsupported_invalidate_mappings(struct dma_buf_attachment *attach)
> > +{
> > +	pr_warn("Invalidate callback should not be called when memory is pinned\n");
> > +}
> > +EXPORT_SYMBOL_FOR_MODULES(dma_buf_unsupported_invalidate_mappings, "ib_uverbs");
> > +
> 
> Well that is exactly the opposite of what I had in mind.
> 
> The RDMA non-ODP case should explicitly not provide an invalidate_mappings callback, but only the dma_buf_attach_ops with allow_peer2peer set to true.
> 
> This is done to explicitly note that RDMA non-ODP can't do invalidation's.

We want to achieve two goals:
1. Provide a meaningful warning to developers, rather than failing later
   because dma_buf_move_notify() was called on this problematic imported dma-buf.
2. Require all users to supply a valid .invalidate_mapping().

If I allow empty .invalidate_mapping(), this check will go too:
   932 struct dma_buf_attachment *
   933 dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
   934                        const struct dma_buf_attach_ops *importer_ops,
   935                        void *importer_priv)
...
   943         if (WARN_ON(importer_ops && !importer_ops->invalidate_mappings))
   944                 return ERR_PTR(-EINVAL);

And it is important part of dma-buf.

Thanks

On 1/21/26 10:14, Leon Romanovsky wrote:
> On Wed, Jan 21, 2026 at 09:59:59AM +0100, Christian König wrote:
>> On 1/20/26 15:07, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@nvidia.com>
>>>
>>> The .invalidate_mapping() callback is documented as optional, yet it
>>> effectively became mandatory whenever importer_ops were provided. This
>>> led to cases where RDMA non-ODP code had to supply an empty stub just to
>>> provide allow_peer2peer.
>>>
>>> Document this behavior by creating a dedicated export for the
>>> dma_buf_unsupported_invalidate_mappings() function. This function is
>>> intended solely for the RDMA non-ODP case and must not be used by any
>>> other dma-buf importer.
>>>
>>> This makes it possible to rely on a valid .invalidate_mappings()
>>> callback to determine whether an importer supports revocation.
>>>
>>> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
>>> ---
>>>  drivers/dma-buf/dma-buf.c             | 14 ++++++++++++++
>>>  drivers/infiniband/core/umem_dmabuf.c | 11 +----------
>>>  include/linux/dma-buf.h               |  4 +++-
>>>  3 files changed, 18 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index cd3b60ce4863..c4fa35034b92 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -1238,6 +1238,20 @@ void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
>>>  }
>>>  EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, "DMA_BUF");
>>>  
>>> +/*
>>> + * This function shouldn't be used by anyone except RDMA non-ODP case.
>>> + * The reason to it is UAPI mistake where dma-buf was exported to the
>>> + * userspace without knowing that .invalidate_mappings() can be called
>>> + * for pinned memory too.
>>> + *
>>> + * This warning shouldn't be seen in real production scenario.
>>> + */
>>> +void dma_buf_unsupported_invalidate_mappings(struct dma_buf_attachment *attach)
>>> +{
>>> +	pr_warn("Invalidate callback should not be called when memory is pinned\n");
>>> +}
>>> +EXPORT_SYMBOL_FOR_MODULES(dma_buf_unsupported_invalidate_mappings, "ib_uverbs");
>>> +
>>
>> Well that is exactly the opposite of what I had in mind.
>>
>> The RDMA non-ODP case should explicitly not provide an invalidate_mappings callback, but only the dma_buf_attach_ops with allow_peer2peer set to true.
>>
>> This is done to explicitly note that RDMA non-ODP can't do invalidation's.
> 
> We want to achieve two goals:
> 1. Provide a meaningful warning to developers, rather than failing later
>    because dma_buf_move_notify() was called on this problematic imported dma-buf.
> 2. Require all users to supply a valid .invalidate_mapping().

Nope, that is something I would reject. invalidate_mappings must stay optional.

> 
> If I allow empty .invalidate_mapping(), this check will go too:

Correct, that is the whole idea.

>    932 struct dma_buf_attachment *
>    933 dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>    934                        const struct dma_buf_attach_ops *importer_ops,
>    935                        void *importer_priv)
> ...
>    943         if (WARN_ON(importer_ops && !importer_ops->invalidate_mappings))
>    944                 return ERR_PTR(-EINVAL);
> 
> And it is important part of dma-buf.

No, as far as I can see that is what we try to avoid.

The whole idea is to make invalidate_mappings truly optional.

Regards,
Christian.

> 
> Thanks

On Wed, Jan 21, 2026 at 10:17:16AM +0100, Christian König wrote:
> The whole idea is to make invalidate_mappings truly optional.

But it's not really optional! It's absence means we are ignoring UAF
security issues when the exporters do their move_notify() and nothing
happens.

Given this I don't want to loose the warning log either, the situation
needs to be reported..

Jason

On 1/21/26 14:18, Jason Gunthorpe wrote:
> On Wed, Jan 21, 2026 at 10:17:16AM +0100, Christian König wrote:
>> The whole idea is to make invalidate_mappings truly optional.
> 
> But it's not really optional! It's absence means we are ignoring UAF
> security issues when the exporters do their move_notify() and nothing
> happens.

No that is unproblematic.

See the invalidate_mappings callback just tells the importer that the mapping in question can't be relied on any more.

But the mapping is truly freed only by the importer calling dma_buf_unmap_attachment().

In other words the invalidate_mappings give the signal to the importer to disable all operations and the dma_buf_unmap_attachment() is the signal from the importer that the housekeeping structures can be freed and the underlying address space or backing object re-used.

Regards,
Christian.

> 
> Given this I don't want to loose the warning log either, the situation
> needs to be reported..
> 
> Jason

On Wed, Jan 21, 2026 at 02:52:53PM +0100, Christian König wrote:
> On 1/21/26 14:18, Jason Gunthorpe wrote:
> > On Wed, Jan 21, 2026 at 10:17:16AM +0100, Christian König wrote:
> >> The whole idea is to make invalidate_mappings truly optional.
> > 
> > But it's not really optional! It's absence means we are ignoring UAF
> > security issues when the exporters do their move_notify() and nothing
> > happens.
> 
> No that is unproblematic.
> 
> See the invalidate_mappings callback just tells the importer that
> the mapping in question can't be relied on any more.
> 
> But the mapping is truly freed only by the importer calling
> dma_buf_unmap_attachment().
> 
> In other words the invalidate_mappings give the signal to the
> importer to disable all operations and the
> dma_buf_unmap_attachment() is the signal from the importer that the
> housekeeping structures can be freed and the underlying address
> space or backing object re-used.

I see

Can we document this please, I haven't seen this scheme described
anyhwere.

And let's clarify what I said in my other email that this new revoke
semantic is not just a signal to maybe someday unmap but a hard
barrier that it must be done once the fences complete, similar to
non-pinned importers.

The cover letter should be clarified with this understanding too.

Jason

On 1/21/26 14:59, Jason Gunthorpe wrote:
> On Wed, Jan 21, 2026 at 02:52:53PM +0100, Christian König wrote:
>> On 1/21/26 14:18, Jason Gunthorpe wrote:
>>> On Wed, Jan 21, 2026 at 10:17:16AM +0100, Christian König wrote:
>>>> The whole idea is to make invalidate_mappings truly optional.
>>>
>>> But it's not really optional! It's absence means we are ignoring UAF
>>> security issues when the exporters do their move_notify() and nothing
>>> happens.
>>
>> No that is unproblematic.
>>
>> See the invalidate_mappings callback just tells the importer that
>> the mapping in question can't be relied on any more.
>>
>> But the mapping is truly freed only by the importer calling
>> dma_buf_unmap_attachment().
>>
>> In other words the invalidate_mappings give the signal to the
>> importer to disable all operations and the
>> dma_buf_unmap_attachment() is the signal from the importer that the
>> housekeeping structures can be freed and the underlying address
>> space or backing object re-used.
> 
> I see
> 
> Can we document this please, I haven't seen this scheme described
> anyhwere.
> 
> And let's clarify what I said in my other email that this new revoke
> semantic is not just a signal to maybe someday unmap but a hard
> barrier that it must be done once the fences complete, similar to
> non-pinned importers.

Well, I would avoid that semantics.

Even when the exporter requests the mapping to be invalidated it does not mean that the mapping can go away immediately.

It's fine when accesses initiated after an invalidation and then waiting for fences go into nirvana and have undefined results, but they should not trigger PCI AER, warnings from the IOMMU or even worse end up in some MMIO BAR of a newly attached devices.

So if the exporter wants to be 100% sure that nobody is using the mapping any more then it needs to wait for the importer to call dma_buf_unmap_attachment().

> The cover letter should be clarified with this understanding too.

Yeah, completely agree. We really need to flash out that semantics in the documentation.

Regards,
Christian.

> 
> Jason

On Wed, Jan 21, 2026 at 03:15:46PM +0100, Christian König wrote:
> > And let's clarify what I said in my other email that this new revoke
> > semantic is not just a signal to maybe someday unmap but a hard
> > barrier that it must be done once the fences complete, similar to
> > non-pinned importers.
> 
> Well, I would avoid that semantics.
>
> Even when the exporter requests the mapping to be invalidated it
> does not mean that the mapping can go away immediately.
> 
> It's fine when accesses initiated after an invalidation and then
> waiting for fences go into nirvana and have undefined results, but
> they should not trigger PCI AER, warnings from the IOMMU or even
> worse end up in some MMIO BAR of a newly attached devices.

So what's the purpose of the fence if accesses can continue after
waiting for fences?

If we always have to wait for the unmap call, is the importer allowed
to call unmap while its own fences are outstanding?

> So if the exporter wants to be 100% sure that nobody is using the
> mapping any more then it needs to wait for the importer to call
> dma_buf_unmap_attachment().

We are trying to introduce this new idea called "revoke".

Revoke means the exporter does some defined sequence and after the end
of that sequence it knows there are no further DMA or CPU accesses to
its memory at all.

It has to happen in bounded time, so it can't get entangled with
waiting for userspace to do something (eg importer unmap via an ioctl)

It has to be an absolute statement because the VFIO and RDMA exporter
use cases can trigger UAFs and AERs if importers keep accessing.

So, what exactly should the export sequence be? We were proposing to
call invalidate_mapping() and when it returns there is no access.

The fence is missing, so now the sequences includes wait for the
fences.

And now you are saying we have to wait for all unmaps? Not only wait
for the unmaps, but the importers now also must call unmap as part of
their invalidate_mapping() callback.. Is that OK? Do existing
importers do that?

If all the above are yes, then lets document explicitly this is the
required sequence and we can try to make it work. Please say, because
we just don't know and keep getting surprised :)

Thanks,
Jason

On Wed, Jan 21, 2026 at 03:15:46PM +0100, Christian König wrote:
> On 1/21/26 14:59, Jason Gunthorpe wrote:
> > On Wed, Jan 21, 2026 at 02:52:53PM +0100, Christian König wrote:
> >> On 1/21/26 14:18, Jason Gunthorpe wrote:
> >>> On Wed, Jan 21, 2026 at 10:17:16AM +0100, Christian König wrote:
> >>>> The whole idea is to make invalidate_mappings truly optional.
> >>>
> >>> But it's not really optional! It's absence means we are ignoring UAF
> >>> security issues when the exporters do their move_notify() and nothing
> >>> happens.
> >>
> >> No that is unproblematic.
> >>
> >> See the invalidate_mappings callback just tells the importer that
> >> the mapping in question can't be relied on any more.
> >>
> >> But the mapping is truly freed only by the importer calling
> >> dma_buf_unmap_attachment().
> >>
> >> In other words the invalidate_mappings give the signal to the
> >> importer to disable all operations and the
> >> dma_buf_unmap_attachment() is the signal from the importer that the
> >> housekeeping structures can be freed and the underlying address
> >> space or backing object re-used.
> > 
> > I see
> > 
> > Can we document this please, I haven't seen this scheme described
> > anyhwere.
> > 
> > And let's clarify what I said in my other email that this new revoke
> > semantic is not just a signal to maybe someday unmap but a hard
> > barrier that it must be done once the fences complete, similar to
> > non-pinned importers.
> 
> Well, I would avoid that semantics.
> 
> Even when the exporter requests the mapping to be invalidated it does not mean that the mapping can go away immediately.
> 
> It's fine when accesses initiated after an invalidation and then waiting for fences go into nirvana and have undefined results, but they should not trigger PCI AER, warnings from the IOMMU or even worse end up in some MMIO BAR of a newly attached devices.
> 
> So if the exporter wants to be 100% sure that nobody is using the mapping any more then it needs to wait for the importer to call dma_buf_unmap_attachment().
> 
> > The cover letter should be clarified with this understanding too.
> 
> Yeah, completely agree. We really need to flash out that semantics in the documentation.

Someone knowledgeable needs to document this properly, either in the code  
or in the official documentation. A cover letter is not the right place for  
subtle design decisions.

Thanks

> 
> Regards,
> Christian.
> 
> > 
> > Jason
>