On Fri, Mar 17, 2017 at 08:05:47AM +0000, Tvrtko Ursulin wrote: > > On 17/03/2017 07:56, Chris Wilson wrote: > >On Fri, Mar 17, 2017 at 07:47:23AM +0000, Tvrtko Ursulin wrote: > >> > >>On 16/03/2017 20:42, Chris Wilson wrote: > >>>trace_i915_gem_request_out may be used after the request is completed, > >>>and so the request may have been retired on another thread, invalidating > >>>the rq->ctx. Avoid dereferencing rq->ctx in the tracepoint by switching > >>>to the fence context id instead, updating all tracepoints to match. > >>> > >>>Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >>>Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>>--- > >>>drivers/gpu/drm/i915/i915_trace.h | 8 ++++---- > >>>1 file changed, 4 insertions(+), 4 deletions(-) > >>> > >>>diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h > >>>index 5503f5ab1e98..66404c5aee82 100644 > >>>--- a/drivers/gpu/drm/i915/i915_trace.h > >>>+++ b/drivers/gpu/drm/i915/i915_trace.h > >>>@@ -590,7 +590,7 @@ TRACE_EVENT(i915_gem_request_queue, > >>> TP_fast_assign( > >>> __entry->dev = req->i915->drm.primary->index; > >>> __entry->ring = req->engine->id; > >>>- __entry->ctx = req->ctx->hw_id; > >>>+ __entry->ctx = req->fence.context; > >>> __entry->seqno = req->fence.seqno; > >>> __entry->flags = flags; > >>> ), > >>>@@ -637,8 +637,8 @@ DECLARE_EVENT_CLASS(i915_gem_request, > >>> > >>> TP_fast_assign( > >>> __entry->dev = req->i915->drm.primary->index; > >>>- __entry->ctx = req->ctx->hw_id; > >>> __entry->ring = req->engine->id; > >>>+ __entry->ctx = req->fence.context; > >>> __entry->seqno = req->fence.seqno; > >>> __entry->global = req->global_seqno; > >>> ), > >>>@@ -681,7 +681,7 @@ DECLARE_EVENT_CLASS(i915_gem_request_hw, > >>> TP_fast_assign( > >>> __entry->dev = req->i915->drm.primary->index; > >>> __entry->ring = req->engine->id; > >>>- __entry->ctx = req->ctx->hw_id; > >>>+ __entry->ctx = req->fence.context; > >>> __entry->seqno = req->fence.seqno; > >>> __entry->global_seqno = req->global_seqno; > >>> __entry->port = port; > >>>@@ -776,7 +776,7 @@ TRACE_EVENT(i915_gem_request_wait_begin, > >>> TP_fast_assign( > >>> __entry->dev = req->i915->drm.primary->index; > >>> __entry->ring = req->engine->id; > >>>- __entry->ctx = req->ctx->hw_id; > >>>+ __entry->ctx = req->fence.context; > >>> __entry->seqno = req->fence.seqno; > >>> __entry->global = req->global_seqno; > >>> __entry->flags = flags; > >>> > >> > >>Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >> > >>req->engine is fine? No chance of request re-use in the window? > > > >We still hold a reference on the rq, so we don't need to play rcu games > >to acquire a stable rq for the tracepoint. We only need to worry about > >objects whose lifetime is coupled to rq retirement. engine/i915 outlive > >all requests. > > Yes I know, but I thought the problem was request re-cycling. > Becuase how does context go away, dont' we have it pinned until the > following request completes any longer? (To avoid the unpin during > context save.) Correct it is pinned and referenced until the next request/context retires. That just makes the race less likely... Didn't stop CI from hitting it 10% of the time :) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
