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

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Oct 22, 2026 at 02:05:30PM +0200, Thomas Hellström wrote:
> On Thu, 2026-10-22 at 08:52 -0300, Jason Gunthorpe wrote:
> > 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.
> 
> That sounds like detaching and reattaching with a different set of
> options. Would that be a fit?

I don't know. The attachment is the anchor for the invalidations,
having it get replaced may create complicated races. Today we don't
destroy it while HW is active..

I'd probably look at keeping the attachment and replacing the mapping
type list as a first try before leaping to replacing the attachment..

Jason