On Fri, Nov 25, 2016 at 12:39:25PM +0200, Joonas Lahtinen wrote: > On pe, 2016-11-25 at 09:30 +0000, Chris Wilson wrote: > > Before we return the request back to the kmem_cache after a failed > > i915_gem_request_alloc(), we should assert that it has not been added to > > any global state tracking. > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > --- > > drivers/gpu/drm/i915/i915_gem_request.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c > > b/drivers/gpu/drm/i915/i915_gem_request.c > > index bd7b21f70283..ed6cead22a86 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_request.c > > +++ b/drivers/gpu/drm/i915/i915_gem_request.c > > @@ -599,6 +599,11 @@ i915_gem_request_alloc(struct intel_engine_cs *engine, > > > return req; > > > > err_ctx: > > + /* Make sure we didn't add ourselves to external state before freeing */ > > + GEM_BUG_ON(!list_empty(&req->active_list)); > > + GEM_BUG_ON(!list_empty(&req->priotree.signalers_list)); > > + GEM_BUG_ON(!list_empty(&req->priotree.waiters_list)); > > This is some paranoia already, but if you managed to hit it;
Fortunately not. I scoured the init_context to make sure we weren't triggering it - but it is a bug we have had in the past and the reason why requests are so tricky to construct so I thought having some paranoia was worth the documentation. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
