gpu: nvgpu: Fix semaphore race condition

A race condition existed in gk20a_channel_semaphore_wait_fd().
In some instances the semaphore underlying the sync_fence being
waited on would have already signaled. This would cause the
subsequent sync_fence_wait_async() call to return 1 and do
nothing. Normally, the sync_fence_wait_async() call would
release the newly created semaphore but in the above case that
would not happen and hang any channel waiting on that semaphore.

To fix this problem if sync_fence_wait_async() returns 1
immediately release the newly created semaphore.

Bug 1604892

Change-Id: I1f5e811695bb099f71b7762835aba4a7e27362ec
Signed-off-by: Alex Waterman <alexw@nvidia.com>
Reviewed-on: http://git-master/r/935910
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
GVS: Gerrit_Virtual_Submit

1 files changed, 3 insertions, 2 deletions

diff --git a/drivers/gpu/nvgpu/gk20a/sync_gk20a.c b/drivers/gpu/nvgpu/gk20a/sync_gk20a.c
index 8740f0e2..e01c0e9a 100644
--- a/drivers/gpu/nvgpu/gk20a/sync_gk20a.c
+++ b/drivers/gpu/nvgpu/gk20a/sync_gk20a.c
@@ -47,8 +47,9 @@ struct gk20a_sync_pt {
         ktime_t                         dep_timestamp;
 
         /*
-         * A spinlock is necessary since there are times when this lock
-         * will be acquired in interrupt context.
+         * Use a spin lock here since it will have better performance
+         * than a mutex - there should be very little contention on this
+         * lock.
          */
         spinlock_t                      lock;
 };