[Intel-gfx] [PATCH] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump

[Chris Wilson]

On Fri, Oct 09, 2015 at 07:33:23PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> > The error state is purposefully racy as we expect it to be called at any
> > time and so have avoided any locking whilst capturing the crash dump.
> > However, with multi-engine GPUs and multiple CPUs, those races can
> > manifest into OOPSes as we attempt to chase dangling pointers freed on
> > other CPUs. Under discussion are lots of ways to slow down normal
> > operation in order to protect the post-mortem error capture, but what it
> > we take the opposite approach and freeze the machine whilst the error
> > catpure runs (note the GPU may still running, but as long as we don't
> > process any of the results the driver's bookkeeping will be static).
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> One risk I see is that the list walking might still go off the rails when
> we stop the machine right in the middle of a list_move. With that we might
> start scanning the active list (of objects) on one engine and then midway
> through get to another engine and so never see the list_head again,
> looping forever. No idea yet what to do with that.

A move is a del followed by an insertion, you cannot step into an entry
that is the middle of moving lists - don't forget that stop_machine() is
a very heavy memory barrier. Similarly, the list_add() should ensure we
can't step forward into an element that will not lead back to the list.
So I am not convinced that it would be suspectible to that style of
hijacking.

The only alternative I see to list walking, is not to do any from the
error capture and rely on attaching enough information to the request
(along with register state) to be able to do postmortems.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre