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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.)

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux