Messages in this thread | | | Date | Thu, 12 May 2022 09:29:35 +0200 | Subject | Re: [PATCH v4 10/15] drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks | From | 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
| |