[Intel-gfx] [PATCH] drm/i915/gt: Warn about the hidden i915_vma_pin in timeline_get_seqno

[Chris Wilson]

Quoting Maarten Lankhorst (2020-01-31 10:12:36)
> Op 30-01-2020 om 12:58 schreef Chris Wilson:
> > On seqno rollover, we need to allocate ourselves a new cacheline. This
> > might incur grabbing a new page and pinning it into the GGTT, with some
> > rather unfortunate lockdep implications.
> >
> > To avoid a mutex, and more specifically pinning in the GGTT from inside
> > the kernel context being used to flush the GGTT in emergencies, we will
> > likely need to lift the next-cacheline allocation to a pre-reservation.
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/gt/intel_timeline.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c
> > index 465f87b65901..54e1e55f3c81 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
> > @@ -406,6 +406,8 @@ __intel_timeline_get_seqno(struct intel_timeline *tl,
> >       void *vaddr;
> >       int err;
> >  
> > +     might_lock(&tl->gt->ggtt->vm.mutex);
> > +
> >       /*
> >        * If there is an outstanding GPU reference to this cacheline,
> >        * such as it being sampled by a HW semaphore on another timeline,
> 
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> 
> If this breaks on lockdep, it was already broken.

I have to write a selftest to cause seqno wrap on the kernel_context to
readily demonstrate the breakage. :|
-Chris