| Message ID | 20180622105710.8276-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@intel.com> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursulin@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. > + > + 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? Regards, Tvrtko > } > > static void execlists_context_unpin(struct intel_context *ce) >
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@intel.com> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@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
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; + + 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); } static void execlists_context_unpin(struct intel_context *ce)
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@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> --- drivers/gpu/drm/i915/intel_lrc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)