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