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)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 19 Mar 2018 07:42:47 +0000 (08:42 +0100)
commit182c594668e7835aba759b4322ac081fe4eeaf1d
tree9a58e75c3281b10eba231fbc7a93c1a576466e5e
parente19df194b50e48d67b5794479fe92a8cd5564ba5
dma-buf/fence: Fix lock inversion within dma-fence-array

[ Upstream commit 03e4e0a9e02cf703da331ff6cfd57d0be9bf5692 ]

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: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/base/Kconfig
drivers/dma-buf/dma-fence-array.c
include/linux/dma-fence-array.h