BACKPORT:dma-buf/fence: Fix lock inversion within dma-fence-array
authorChris Wilson <chris@chris-wilson.co.uk>
Tue, 14 Nov 2017 16:27:19 +0000 (16:27 +0000)
committerJianxin Pan <jianxin.pan@amlogic.com>
Tue, 7 Aug 2018 10:15:31 +0000 (03:15 -0700)
commit997e954bb05f0a11b6a7023c0bee937ebb52a3f0
tree05b3eedac2ebfe6b628c37d1f0de82bac626e095
parent3491d1638b74c2e67241d1b1917634e8875b9256
BACKPORT:dma-buf/fence: Fix lock inversion within dma-fence-array

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@gmail.com>
Suggested-by: Rob Clark <robdclark@gmail.com>
References: 1476635975-21981-1-git-send-email-robdclark@gmail.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114162719.30958-1-chris@chris-wilson.co.uk
Signed-off-by: Jiyu Yang <Jiyu.Yang@amlogic.com>
Change-Id: Ia08cb17615ff15b18c208cff2000d92344c9f399
drivers/base/Kconfig
drivers/dma-buf/fence-array.c
include/linux/fence-array.h