[SNIP]
Yeah I think long-term it's where we want to be, just trying to findAre you okay with this rule?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."
clever ways to get there.
And I think Christian agrees with that?
So throwing it at intel-gfx-ci can't hurt I think, but that only coversAlrightUnfortunately not really :-/ Only way really is to grab a driver whichIt shouldn't be that hard to clean up. The last time I looked into it myDo we have any tests for dma-bufs at all? It's unclear to me what you
main problem was that we didn't had any easy unit test for it.
are going to test in regards to the reservation locks, could you please
clarify?
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.
i915 so doesn't really help with the bigger issue of catching all the
drivers.
Cheers, Daniel