[Intel-gfx] [PATCH] drm/i915/execlists: Check for ce->state before destroy

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-25 10:35:17)
> 
> On 22/06/2018 11:57, Chris Wilson wrote:
> > As we may cancel the ce->state allocation during context pinning (but
> > crucially after we mark ce as operational), that means we may be asked
> > to destroy a nonexistent ce->state. Given the choice in handing a
> > complex error path on pinning, and just ignoring the lack of state in
> > destroy, choice the latter for simplicity.
> > 
> > Reported-by: Zhao Yakui <yakui.zhao at intel.com>
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > ---
> >   drivers/gpu/drm/i915/intel_lrc.c | 8 ++++++--
> >   1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> > index 33bc914c2ef5..02ee3b12507f 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1337,11 +1337,15 @@ static void execlists_schedule(struct i915_request *request,
> >   
> >   static void execlists_context_destroy(struct intel_context *ce)
> >   {
> > -     GEM_BUG_ON(!ce->state);
> >       GEM_BUG_ON(ce->pin_count);
> >   
> > +     if (!ce->state)
> > +             return;
> 
> Or set ce->ops only after success in execlists_context_pin? Sounds 
> simpler and more logical unless I am missing something.

The error handling!

If I do it this way, it is more consistent with virtual engine as there
ce->ops is not a good guide either. In ve, ops and state are set along
different paths.

In the future, I'm not so sure as then I expect ops to be set on
construction before pinning. But I am still planning on writing that...

> > +
> > +     GEM_BUG_ON(i915_gem_object_is_active(ce->state->obj));
> > +
> >       intel_ring_free(ce->ring);
> > -     __i915_gem_object_release_unless_active(ce->state->obj);
> > +     i915_gem_object_put(ce->state->obj);
> 
> Hm this bit is unexpected. I don't see an immediate intersect with the 
> commit message and previous change. Intuitively it makes sense that 
> ce->state->obj can/must never be active once here - but then doesn't 
> this second part belong in a separate patch?

Fine.
-Chris