[Intel-gfx] [PATCH 02/39] drm/i915: Refine i915_reset.lock_map

Chris Wilson chris at chris-wilson.co.uk
Fri Jun 14 14:17:23 UTC 2019


Quoting Mika Kuoppala (2019-06-14 15:10:08)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index 1cbc3ef4fc27..5311286578b7 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1444,7 +1444,15 @@ long i915_request_wait(struct i915_request *rq,
> >               return -ETIME;
> >  
> >       trace_i915_request_wait_begin(rq, flags);
> > -     lock_map_acquire(&rq->i915->gt.reset_lockmap);
> > +
> > +     /*
> > +      * We must never wait on the GPU while holding a lock as we
> > +      * may need to perform a GPU reset. So while we don't need to
> > +      * serialise wait/reset with an explicit lock, we do want
> > +      * lockdep to detect potential dependency cycles.
> > +      */
> > +     mutex_acquire(&rq->i915->gpu_error.wedge_mutex.dep_map,
> > +                   0, 0, _THIS_IP_);
> 
> Seems to translate to exclusive lock with full checking.
> 
> There was ofcourse a slight possibilty that previous reviewer did
> read all the lockdep.h. Looked at the wedge mutex and connected
> the dots. Well, it is obvious now.

Hah, I had forgotten all about wedge_mutex :-p

Hopefully, this keeps our reset handling robust. First I have to fix the
mistakes I've recently made...

I just need to find a reviewer for struct_mutex removal :)
-Chris


More information about the Intel-gfx mailing list