[PATCH] dma-buf/fence: Fix lock inversion within dma-fence-array
Chris Wilson
chris at chris-wilson.co.uk
Wed Nov 15 13:20:20 UTC 2017
Quoting Chris Wilson (2017-11-14 16:27:19)
> Ages ago Rob Clark noted,
>
> "Currently with fence-array, we have a potential deadlock situation. If
> we fence_add_callback() on an array-fence, the array-fence's lock is
> acquired first, and in it's ->enable_signaling() callback, it will install
> cbs on it's array-member fences, so the array-member's lock is acquired
> second.
>
> But in the signal path, the array-member's lock is acquired first, and
> the array-fence's lock acquired second."
>
> Rob proposed either extensive changes to dma-fence to unnest the
> fence-array signaling, or to defer the signaling onto a workqueue. This
> is a more refined version of the later, that should keep the latency
> of the fence signaling to a minimum by using an irq-work, which is
> executed asap.
>
> Reported-by: Rob Clark <robdclark at gmail.com>
> Suggested-by: Rob Clark <robdclark at gmail.com>
Testcase: igt/sw_sync/sync_multi_timeline_wait
> References: 1476635975-21981-1-git-send-email-robdclark at gmail.com
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Rob Clark <robdclark at gmail.com>
> Cc: Gustavo Padovan <gustavo.padovan at collabora.co.uk>
> Cc: Sumit Semwal <sumit.semwal at linaro.org>
> Cc: Christian König <christian.koenig at amd.com>
More information about the dri-devel
mailing list