Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks

[Christian König]

Am 11.05.22 um 21:05 schrieb Daniel Vetter:
> [SNIP]
> > > > It's unclear to me which driver may ever want to do the mapping under
> > > > the dma_resv_lock. But if we will ever have such a driver that will need
> > > > to map imported buffer under dma_resv_lock, then we could always add the
> > > > dma_buf_vmap_locked() variant of the function. In this case the locking
> > > > rule will sound like this:
> > > >
> > > > "All dma-buf importers are responsible for holding the dma-reservation
> > > > lock around the dmabuf->ops->mmap/vmap() calls."
> > Are you okay with this rule?
> Yeah I think long-term it's where we want to be, just trying to find
> clever ways to get there.
>
> And I think Christian agrees with that?

Yes, completely.

A design where most DMA-buf functions are supposed to be called with the 
reservation lock held is exactly what I have in mind for the long term.

> > > > > It shouldn't be that hard to clean up. The last time I looked into it my
> > > > > main problem was that we didn't had any easy unit test for it.
> > > > Do we have any tests for dma-bufs at all? It's unclear to me what you
> > > > are going to test in regards to the reservation locks, could you please
> > > > clarify?
> > > Unfortunately not really :-/ Only way really is to grab a driver which
> > > needs vmap (those are mostly display drivers) on an imported buffer, and
> > > see what happens.
> > >
> > > 2nd best is liberally sprinkling lockdep annotations all over the place
> > > and throwing it at intel ci (not sure amd ci is accessible to the public)
> > > and then hoping that's good enough. Stuff like might_lock and
> > > dma_resv_assert_held.
> > Alright
> So throwing it at intel-gfx-ci can't hurt I think, but that only covers
> i915 so doesn't really help with the bigger issue of catching all the
> drivers.

BTW: We have now somebody working on converting the existing 
libdrm_amdgpu unit tests over to igt.

Regards,
Christian.

> Cheers, Daniel