Quoting Tvrtko Ursulin (2017-09-19 11:19:25) > > On 11/09/2017 09:41, Chris Wilson wrote: > > A fence may be signaled from any context, including from inside a timer. > > One example is timer_i915_sw_fence_wake() which is used to provide a > > safety-net when waiting on an external fence. If the external fence is > > not signaled within a timely fashion, we signal our fence on its behalf, > > and so we then may process subsequent fences in the chain from within > > that timer context. > > > > Given that dma_i915_sw_fence_cb() may be from inside a timer, we cannot > > s/dma_i915_sw_fence_cb/dma_i915_sw_fence_wake/ ? > > > then use del_timer_sync() as that requires the timer lock for itself. To > > circumvent this, while trying to keep the signal propagation as low > > latency as possible, move the completion into a worker and use a bit of > > atomic switheroo to serialise the timer-callback and the dma-callback. > > > > Testcase: igt/gem_eio/in-flight-external > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > Okay it took me a few minutes to figure it out. Looks correct. > > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Ta, fixed up the bad reference and pushed this along with the igt that was happily deadlocking the kernel. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
