Commit 73e2232a authored Mar 07, 2018 by Chris Wilson Committed by Joonas Lahtinen Mar 16, 2018

drm/i915: Only call tasklet_kill() on the first prepare_reset



tasklet_kill() will spin waiting for the current tasklet to be executed.
However, if tasklet_disable() has been called, then the tasklet is never
executed but permanently put back onto the runlist until
tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
disable/enable pair. This is the case when we call set-wedge from inside
i915_reset(), and another request was submitted to us concurrent to the
reset.

Fixes: 963ddd63 ("drm/i915: Suspend submission tasklets around wedging")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180307134226.25492-6-chris@chris-wilson.co.uk


(cherry picked from commit 68ad3612)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

parent 7e9d3a4a

drivers/gpu/drm/i915/i915_gem.c

+9 −1

Original line number	Diff line number	Diff line
		@@ -2940,7 +2940,15 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
		* calling engine->init_hw() and also writing the ELSP.
		* Turning off the execlists->tasklet until the reset is over
		* prevents the race.
		*/
		*
		* Note that this needs to be a single atomic operation on the
		* tasklet (flush existing tasks, prevent new tasks) to prevent
		* a race between reset and set-wedged. It is not, so we do the best
		* we can atm and make sure we don't lock the machine up in the more
		* common case of recursively being called from set-wedged from inside
		* i915_reset.
		*/
		if (!atomic_read(&engine->execlists.tasklet.count))
		tasklet_kill(&engine->execlists.tasklet);
		tasklet_disable(&engine->execlists.tasklet);