Re: [PATCH v2 0/4] dma-buf: document revoke mechanism to invalidate shared buffers

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Mon, 2026-01-19 at 12:24 -0400, Jason Gunthorpe wrote:
> On Mon, Jan 19, 2026 at 10:27:00AM +0100, Thomas Hellström wrote:
> > this sounds like it's not just undocumented but also in some cases
> > unimplemented. The xe driver for one doesn't expect move_notify()
> > to be
> > called on pinned buffers, so if that is indeed going to be part of
> > the
> > dma-buf protocol,  wouldn't support for that need to be advertised
> > by
> > the importer?
> 
> Can you clarify this?
> 
> I don't see xe's importer calling dma_buf_pin() or dma_buf_attach()
> outside of tests? It's importer implements a fully functional looking
> dynamic attach with move_notify()?
> 
> I see the exporer is checking for pinned and then not calling
> move_notify - is that what you mean?

No it was if move_notify() is called on a pinned buffer, things will
probably blow up.

And I was under the impression that we'd might be pinning imported
framebuffers but either we don't get any of those or we're using the
incorrect interface to pin, so it might not be a big issue from the xe
side. Need to check this.

In any case we'd want to support revoking also of pinned buffers moving
forward, so question really becomes whether in the mean-time we need to
flag somehow that we don't support it.

Thanks,
Thomas


> 
> When I looked through all the importers only RDMA obviously didn't
> support move_notify on pinned buffers.
> 
> Jason