[Intel-gfx] [PATCH] drm/i915: Avoid use-after-free of ctx in request tracepoints

[Chris Wilson]

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 at chris-wilson.co.uk>
> >>>Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>>---
> >>>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 at intel.com>
> >>
> >>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