[Intel-gfx] [PATCH v3] drm/i915: Break modeset deadlocks on reset

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-23 13:35:24)
> 
> On 22/06/2017 11:56, Chris Wilson wrote:
> > Trying to do a modeset from within a reset is fraught with danger. We
> > can fall into a cyclic deadlock where the modeset is waiting on a
> > previous modeset that is waiting on a request, and since the GPU hung
> > that request completion is waiting on the reset. As modesetting doesn't
> > allow its locks to be broken and restarted, or for its *own* reset
> > mechanism to take over the display, we have to do something very
> > evil instead. If we detect that we are stuck waiting to prepare the
> > display reset (by using a very simple timeout), resort to cancelling all
> > in-flight requests and throwing the user data into /dev/null, which is
> > marginally better than the driver locking up and keeping that data to
> > itself.
> > 
> > This is not a fix; this is just a workaround that unbreaks machines
> > until we can resolve the deadlock in a way that doesn't lose data!
> > 
> > v2: Move the retirement from set-wegded to the i915_reset() error path,
> > after which we no longer any delayed worker cleanup for
> > i915_handle_error()
> > v3: C abuse for syntactic sugar
> > v4: Cover all waits with the timeout to catch more driver breakage
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=99093
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala at intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> [snip]
> Looks OK - lets see how temporary it will end up being. :)

I've grown to like the idea of having a watchdog here. We critically
depend on reset to ensure forward progress of requests, and this gives
us that extra layer of paranoid protection.
 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Thanks, the real magic is still to come :)
-Chris