summaryrefslogtreecommitdiff
path: root/drivers/net/xen-netback/interface.c
diff options
context:
space:
mode:
authorTomasz Figa <tfiga@chromium.org>2017-02-22 18:23:05 +0900
committerFiroz Khan <firozk@codeaurora.org>2019-01-31 12:40:26 +0530
commit6693b0baa7d29c1de4f3b30cb0b75ee144230923 (patch)
treeed4a7abd6a29c541df4651e3c08bd363970eb4a6 /drivers/net/xen-netback/interface.c
parent1bc2a5fa8337018731393b8d6b2f83203ff0f5d3 (diff)
staging: android/sync: Signal fences if timeline is destroyed
The original implementation of sw_sync in 3.14 kernel signaled all active fences with error status on timeline release. However, after the conversion to use DMA-buf fence code under the hood, the behavior was (most likely by mistake) changed and the fences are being left active, with their users possibly getting stuck in sync_wait(). There is indeed a sign of this not being an intentional behavior change, as timeline retained its ->destroyed field, which is being set in sync_timeline_destroy(). However there is no code checking it anymore. Let's fix this by adding a check for timeline->destroyed in android_fence_signaled(), so if the fence is neither signaled nor in error state and timeline was destroyed, it will end up in -ENOENT error state. Change-Id: I0313b12b37e9d391d5caf218f381fa4b07a2a5e5 Signed-off-by: Tomasz Figa <tfiga@chromium.org> Git-commit: 85839014db07d3c675d5a8f2f9f94f2aeb33fc5e Git-repo: https://chromium.googlesource.com/chromiumos/third_party/kernel Signed-off-by: Firoz Khan <firozk@codeaurora.org>
Diffstat (limited to 'drivers/net/xen-netback/interface.c')
0 files changed, 0 insertions, 0 deletions