Re: [PATCH RFC 01/26] dma-buf: Introduce DMA-buf mapping types

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Oct 22, 2026 at 09:25:55AM +0200, Thomas Hellström wrote:
> > Attachment could also scan existing attachments to preferentially
> > pick matching
> > mapping_types that are compatible with existing attachments, thus
> > avoiding
> > invalidation where possible.
> 
> Current design appears to be that attach only determines the set of
> theoretically possible mapping types, disregarding other attachments. 
> Taking other attachments into account is also problematic because the
> dma-resv lock is not held.

Stating my restriction in a different way, the attach may start with
{ualink, pcie} as options. Then we do the first map and select ualink.

Then we get an invalidation and do a second map. Here we need a way to
change the mapping type options to {ualink}.

The exporter would have to make the memory visible on ualink to
succeed the map.

> Looking at current GPU drivers, what you describe above is typically
> done at pin() time, but if some importers want an early very likely
> decision on what mapping_type to use, one could introduce a separate
> function that match the mapping_types, but that would be very similar
> to the map() function but without returning a sgt/mapping, or a pin()
> without actually pinning. One could reuse the invalidate_mappings()
> callback to indicate the mapping type is no longer valid?

I don't know that anyone needs a very early decision, but mlx5
certainly needs something like the above flow..

Jason