On 8/24/22 18:14, Christian König wrote: > Am 24.08.22 um 17:03 schrieb Dmitry Osipenko: >> On 8/24/22 17:08, Christian König wrote: >>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >>>> Move dma-buf attachment API functions to the dynamic locking >>>> specification. >>>> The strict locking convention prevents deadlock situations for dma-buf >>>> importers and exporters. >>>> >>>> Previously, the "unlocked" versions of the attachment API functions >>>> weren't taking the reservation lock and this patch makes them to take >>>> the lock. >>> Didn't we concluded that we need to keep the attach and detach callbacks >>> without the lock and only move the map/unmap callbacks over? >>> >>> Otherwise it won't be possible for drivers to lock multiple buffers if >>> they have to shuffle things around for a specific attachment. >> We did conclude that. The attach/detach dma-buf ops are unlocked, but >> the map_dma_buf/unmap_dma_buf must be invoked under lock and >> dma_buf_dynamic_attach_unlocked() maps dma-buf if either importer or >> exporter can't handle the dynamic mapping [1]. > > Ah! You are confusing me over and over again with that :) > > Ok in this case that here is fine, I just need to re-read the patch.
It's indeed not trivial to review this patch, not sure if we can make it simpler. Maybe it's possible to factor out the changes related to dynamic mapping, or maybe it's not worthwhile.. Anyways, thank you for helping with reviewing it :) -- Best regards, Dmitry
