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
