Quoting Andi Shyti (2021-01-14 03:01:15)
> Hi Chris,
>
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index 0b1a46a0d866..784c05ac5cca 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -276,7 +276,7 @@ static void remove_from_engine(struct i915_request *rq)
> >
> > bool i915_request_retire(struct i915_request *rq)
> > {
> > - if (!i915_request_completed(rq))
> > + if (!__i915_request_is_complete(rq))
>
>
> > return false;
> >
> > RQ_TRACE(rq, "\n");
> > @@ -342,8 +342,7 @@ void i915_request_retire_upto(struct i915_request *rq)
> > struct i915_request *tmp;
> >
> > RQ_TRACE(rq, "\n");
> > -
> > - GEM_BUG_ON(!i915_request_completed(rq));
> > + GEM_BUG_ON(!__i915_request_is_complete(rq));
>
> I might be a bit shallow, but where is the lock here?
This holds the request->context->timeline->mutex.
The locking is basically split between frontend/backend:
construction/destruction - under the timeline->mutex
execution - under the engine->active.lock (coordinates with
timeline->mutex)
At all other times, RCU protected access (using the SLAB_TYPESAFE_BY_RCU
so approach with caution).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
