[Intel-gfx] [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem

[Daniel Vetter]

On Wed, Jan 27, 2016 at 04:44:37PM +0000, Chris Wilson wrote:
> On Wed, Jan 27, 2016 at 03:43:49PM +0000, daniele.ceraolospurio at intel.com wrote:
> > From: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> > 
> > While running some tests on the scheduler patches with rpm enabled I
> > came across a corruption in the ringbuffer, which was root-caused to
> > the GPU being suspended while commands were being emitted to the
> > ringbuffer. The access to memory was failing because the GPU needs to
> > be awake when accessing stolen memory (where my ringbuffer was located).
> > Since we have this constraint it looks like a sensible idea to check
> > that we hold a refcount when we access the rungbuffer.
> > 
> > v2: move the check from ring_begin to ringbuffer iomap time (Chris)
> > v3: update comment (Chris)
> > 
> > Cc: John Harrison <John.C.Harrison at Intel.com>
> > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> 
> That explains itself nicely, thanks.
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>

Queued for -next, thanks for the patch.

> It also rings alarms bells for intel_fbdev.c

Oops, indeed. Might explain why we sometimes just die? And fundamentally
it's unfixable (without a shadow fb) since we can't intercept mmaps on
fbdev. But maybe we need to do that (and use the damage tracking that's
already there in 3 copies in various drivers for uploading).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch