]> git.baikalelectronics.ru Git - kernel.git/commit
drm/i915: Lock signaler timeline while navigating
authorChris Wilson <chris@chris-wilson.co.uk>
Thu, 19 Sep 2019 11:19:11 +0000 (12:19 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Fri, 20 Sep 2019 09:24:12 +0000 (10:24 +0100)
commit73beb8b8b5515a5f499f0aea198eaa05c86d0e37
tree059368a3e2efd56aa6db6f1a6802ece9dd5a1db9
parent942ff3ffbb6fe08164d886b8ed670d7d3e2e5f99
drm/i915: Lock signaler timeline while navigating

As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!

Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.

v2: Tvrtko made me realise I was being lax and using annotations to
ignore the AB-BA deadlock from the timeline overlap. As it would be
possible to construct a second request that was using a semaphore from the
same timeline as ourselves, we could quite easily end up in a situation
where we deadlocked in our mutex waits. Avoid that by using a trylock
and falling back to a normal dma-fence await if contended.

v3: Eek, the signal->timeline is volatile and must be carefully
dereferenced to ensure it is valid.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-2-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/i915_request.c