All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 07/40] drm/i915: Seal races between async GPU cancellation, retirement and signaling
Date: Wed, 8 May 2019 11:21:00 +0100	[thread overview]
Message-ID: <abd68952-c310-3cfd-d00f-4a209ccbdb21@linux.intel.com> (raw)
In-Reply-To: <20190508080704.24223-7-chris@chris-wilson.co.uk>


On 08/05/2019 09:06, Chris Wilson wrote:
> Currently there is an underlying assumption that i915_request_unsubmit()
> is synchronous wrt the GPU -- that is the request is no longer in flight
> as we remove it. In the near future that may change, and this may upset
> our signaling as we can process an interrupt for that request while it
> is no longer in flight.
> 
> CPU0					CPU1
> intel_engine_breadcrumbs_irq
> (queue request completion)
> 					i915_request_cancel_signaling
> ...					...
> 					i915_request_enable_signaling
> dma_fence_signal
> 
> Hence in the time it took us to drop the lock to signal the request, a
> preemption event may have occurred and re-queued the request. In the
> process, that request would have seen I915_FENCE_FLAG_SIGNAL clear and
> so reused the rq->signal_link that was in use on CPU0, leading to bad
> pointer chasing in intel_engine_breadcrumbs_irq.
> 
> A related issue was that if someone started listening for a signal on a
> completed but no longer in-flight request, we missed the opportunity to
> immediately signal that request.
> 
> Furthermore, as intel_contexts may be immediately released during
> request retirement, in order to be entirely sure that
> intel_engine_breadcrumbs_irq may no longer dereference the intel_context
> (ce->signals and ce->signal_link), we must wait for irq spinlock.
> 
> In order to prevent the race, we use a bit in the fence.flags to signal
> the transfer onto the signal list inside intel_engine_breadcrumbs_irq.
> For simplicity, we use the DMA_FENCE_FLAG_SIGNALED_BIT as it then
> quickly signals to any outside observer that the fence is indeed signaled.
> 
> v2: Sketch out potential dma-fence API for manual signaling
> 
> Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   drivers/dma-buf/dma-fence.c                 |  1 +
>   drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 70 ++++++++++++++-------
>   drivers/gpu/drm/i915/i915_request.c         |  1 +
>   drivers/gpu/drm/i915/intel_guc_submission.c |  1 -
>   4 files changed, 51 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 3aa8733f832a..9bf06042619a 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -29,6 +29,7 @@
>   
>   EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
>   EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
> +EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
>   
>   static DEFINE_SPINLOCK(dma_fence_stub_lock);
>   static struct dma_fence dma_fence_stub;
> diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> index fe455f01aa65..7053a90e5cb5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> @@ -23,6 +23,7 @@
>    */
>   
>   #include <linux/kthread.h>
> +#include <trace/events/dma_fence.h>
>   #include <uapi/linux/sched/types.h>
>   
>   #include "i915_drv.h"
> @@ -96,9 +97,30 @@ check_signal_order(struct intel_context *ce, struct i915_request *rq)
>   	return true;
>   }
>   
> +static void
> +__dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp)
> +{
> +	fence->timestamp = timestamp;
> +	set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags);
> +	trace_dma_fence_signaled(fence);
> +}
> +
> +static void
> +__dma_fence_signal_notify(struct dma_fence *fence)
> +{
> +	struct dma_fence_cb *cur, *tmp;
> +
> +	list_for_each_entry_safe(cur, tmp, &fence->cb_list, node) {
> +		INIT_LIST_HEAD(&cur->node);
> +		cur->func(fence, cur);
> +	}
> +	INIT_LIST_HEAD(&fence->cb_list);
> +}
> +
>   void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
>   {
>   	struct intel_breadcrumbs *b = &engine->breadcrumbs;
> +	const ktime_t timestamp = ktime_get();
>   	struct intel_context *ce, *cn;
>   	struct list_head *pos, *next;
>   	LIST_HEAD(signal);
> @@ -122,6 +144,11 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
>   
>   			GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_SIGNAL,
>   					     &rq->fence.flags));
> +			clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
> +
> +			if (test_and_set_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> +					     &rq->fence.flags))

I wanted this direct/open-coded manipulation to also be clearly called 
out for.

To follow the convention in other helpers here, if you could wrap it in 
something like __dma_fence_signal_return I could live with it.

Regards,

Tvrtko

> +				continue;
>   
>   			/*
>   			 * Queue for execution after dropping the signaling
> @@ -129,14 +156,6 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
>   			 * more signalers to the same context or engine.
>   			 */
>   			i915_request_get(rq);
> -
> -			/*
> -			 * We may race with direct invocation of
> -			 * dma_fence_signal(), e.g. i915_request_retire(),
> -			 * so we need to acquire our reference to the request
> -			 * before we cancel the breadcrumb.
> -			 */
> -			clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
>   			list_add_tail(&rq->signal_link, &signal);
>   		}
>   
> @@ -159,7 +178,12 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
>   		struct i915_request *rq =
>   			list_entry(pos, typeof(*rq), signal_link);
>   
> -		dma_fence_signal(&rq->fence);
> +		__dma_fence_signal_timestamp(&rq->fence, timestamp);
> +
> +		spin_lock(&rq->lock);
> +		__dma_fence_signal_notify(&rq->fence);
> +		spin_unlock(&rq->lock);
> +
>   		i915_request_put(rq);
>   	}
>   }
> @@ -261,19 +285,17 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
>   
>   bool i915_request_enable_breadcrumb(struct i915_request *rq)
>   {
> -	struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
> -
> -	GEM_BUG_ON(test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags));
> -
> -	if (!test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags))
> -		return true;
> +	lockdep_assert_held(&rq->lock);
> +	lockdep_assert_irqs_disabled();
>   
> -	spin_lock(&b->irq_lock);
> -	if (test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags) &&
> -	    !__request_completed(rq)) {
> +	if (test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
> +		struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
>   		struct intel_context *ce = rq->hw_context;
>   		struct list_head *pos;
>   
> +		spin_lock(&b->irq_lock);
> +		GEM_BUG_ON(test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags));
> +
>   		__intel_breadcrumbs_arm_irq(b);
>   
>   		/*
> @@ -303,8 +325,8 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
>   		GEM_BUG_ON(!check_signal_order(ce, rq));
>   
>   		set_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
> +		spin_unlock(&b->irq_lock);
>   	}
> -	spin_unlock(&b->irq_lock);
>   
>   	return !__request_completed(rq);
>   }
> @@ -313,9 +335,15 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq)
>   {
>   	struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
>   
> -	if (!test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
> -		return;
> +	lockdep_assert_held(&rq->lock);
> +	lockdep_assert_irqs_disabled();
>   
> +	/*
> +	 * We must wait for b->irq_lock so that we know the interrupt handler
> +	 * has released its reference to the intel_context and has completed
> +	 * the DMA_FENCE_FLAG_SIGNALED_BIT/I915_FENCE_FLAG_SIGNAL dance (if
> +	 * required).
> +	 */
>   	spin_lock(&b->irq_lock);
>   	if (test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags)) {
>   		struct intel_context *ce = rq->hw_context;
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 9510db566a58..cbe4098cd6ec 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -437,6 +437,7 @@ void __i915_request_submit(struct i915_request *request)
>   	set_bit(I915_FENCE_FLAG_ACTIVE, &request->fence.flags);
>   
>   	if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags) &&
> +	    !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &request->fence.flags) &&
>   	    !i915_request_enable_breadcrumb(request))
>   		intel_engine_queue_breadcrumbs(engine);
>   
> diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c
> index 380d83a2bfb6..ea0e3734d37c 100644
> --- a/drivers/gpu/drm/i915/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/intel_guc_submission.c
> @@ -23,7 +23,6 @@
>    */
>   
>   #include <linux/circ_buf.h>
> -#include <trace/events/dma_fence.h>
>   
>   #include "gt/intel_engine_pm.h"
>   #include "gt/intel_lrc_reg.h"
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-05-08 10:21 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08  8:06 [PATCH 01/40] drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD Chris Wilson
2019-05-08  8:06 ` [PATCH 02/40] drm/i915: Rearrange i915_scheduler.c Chris Wilson
2019-05-08  8:06 ` [PATCH 03/40] drm/i915: Pass i915_sched_node around internally Chris Wilson
2019-05-08 10:15   ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 04/40] drm/i915: Check for no-op priority changes first Chris Wilson
2019-05-08 10:16   ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 05/40] drm/i915: Bump signaler priority on adding a waiter Chris Wilson
2019-05-08  8:06 ` [PATCH 06/40] drm/i915: Convert inconsistent static engine tables into an init error Chris Wilson
2019-05-08  8:06 ` [PATCH 07/40] drm/i915: Seal races between async GPU cancellation, retirement and signaling Chris Wilson
2019-05-08 10:21   ` Tvrtko Ursulin [this message]
2019-05-08 11:24   ` [PATCH] " Chris Wilson
2019-05-08 11:50     ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 08/40] dma-fence: Refactor signaling for manual invocation Chris Wilson
2019-05-08 11:25   ` [PATCH] " Chris Wilson
2019-05-08 11:52     ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 09/40] drm/i915: Restore control over ppgtt for context creation ABI Chris Wilson
2019-05-08 10:24   ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 10/40] drm/i915: Allow a context to define its set of engines Chris Wilson
2019-05-08  8:06 ` [PATCH 11/40] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[] Chris Wilson
2019-05-08 10:25   ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 12/40] drm/i915: Re-expose SINGLE_TIMELINE flags for context creation Chris Wilson
2019-05-08 10:26   ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 13/40] drm/i915: Allow userspace to clone contexts on creation Chris Wilson
2019-05-08  8:06 ` [PATCH 14/40] drm/i915: Load balancing across a virtual engine Chris Wilson
2019-05-08 10:29   ` Tvrtko Ursulin
2019-05-08 11:17     ` Chris Wilson
2019-05-08 11:36       ` Tvrtko Ursulin
2019-05-08 11:23   ` [PATCH] " Chris Wilson
2019-05-08 11:35     ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 15/40] drm/i915: Apply an execution_mask to the virtual_engine Chris Wilson
2019-05-08 10:13   ` Tvrtko Ursulin
2019-05-08  8:06 ` [PATCH 16/40] drm/i915: Extend execution fence to support a callback Chris Wilson
2019-05-08  8:06 ` [PATCH 17/40] drm/i915/execlists: Virtual engine bonding Chris Wilson
2019-05-08  8:06 ` [PATCH 18/40] drm/i915: Allow specification of parallel execbuf Chris Wilson
2019-05-08  8:06 ` [PATCH 19/40] drm/i915: Split GEM object type definition to its own header Chris Wilson
2019-05-08  8:06 ` [PATCH 20/40] drm/i915: Pull GEM ioctls interface to its own file Chris Wilson
2019-05-08  8:06 ` [PATCH 21/40] drm/i915: Move object->pages API to i915_gem_object.[ch] Chris Wilson
2019-05-08  8:06 ` [PATCH 22/40] drm/i915: Move shmem object setup to its own file Chris Wilson
2019-05-08  8:06 ` [PATCH 23/40] drm/i915: Move phys objects " Chris Wilson
2019-05-08  8:06 ` [PATCH 24/40] drm/i915: Move mmap and friends " Chris Wilson
2019-05-08  8:06 ` [PATCH 25/40] drm/i915: Move GEM domain management " Chris Wilson
2019-05-08  8:06 ` [PATCH 26/40] drm/i915: Move more GEM objects under gem/ Chris Wilson
2019-05-08  8:06 ` [PATCH 27/40] drm/i915: Pull scatterlist utils out of i915_gem.h Chris Wilson
2019-05-08  8:06 ` [PATCH 28/40] drm/i915: Move GEM object domain management from struct_mutex to local Chris Wilson
2019-05-08  8:06 ` [PATCH 29/40] drm/i915: Move GEM object waiting to its own file Chris Wilson
2019-05-10 14:17   ` Mika Kuoppala
2019-05-10 14:33     ` Chris Wilson
2019-05-08  8:06 ` [PATCH 30/40] drm/i915: Move GEM object busy checking " Chris Wilson
2019-05-10 14:29   ` Mika Kuoppala
2019-05-08  8:06 ` [PATCH 31/40] drm/i915: Move GEM client throttling " Chris Wilson
2019-05-10 14:37   ` Mika Kuoppala
2019-05-08  8:06 ` [PATCH 32/40] drm/i915: Drop the deferred active reference Chris Wilson
2019-05-08  8:06 ` [PATCH 33/40] drm/i915: Move object close under its own lock Chris Wilson
2019-05-08  8:06 ` [PATCH 34/40] drm/i915: Rename intel_context.active to .inflight Chris Wilson
2019-05-10 14:44   ` Mika Kuoppala
2019-05-08  8:06 ` [PATCH 35/40] drm/i915: Keep contexts pinned until after the next kernel context switch Chris Wilson
2019-05-08  8:07 ` [PATCH 36/40] drm/i915: Stop retiring along engine Chris Wilson
2019-05-08  8:07 ` [PATCH 37/40] drm/i915: Replace engine->timeline with a plain list Chris Wilson
2019-05-08  8:07 ` [PATCH 38/40] drm/i915: Flush the execution-callbacks on retiring Chris Wilson
2019-05-08  8:07 ` [PATCH 39/40] drm/i915/execlists: Preempt-to-busy Chris Wilson
2019-05-08  8:07 ` [PATCH 40/40] drm/i915/execlists: Minimalistic timeslicing Chris Wilson
2019-05-08 10:47 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/40] drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD Patchwork
2019-05-08 10:59 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-05-08 11:09 ` ✓ Fi.CI.BAT: success " Patchwork
2019-05-08 11:49 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/40] drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD (rev4) Patchwork
2019-05-08 12:06 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-05-08 12:10 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-05-08 12:30 ` [PATCH 01/40] drm/i915/hangcheck: Replace hangcheck.seqno with RING_HEAD Mika Kuoppala
2019-05-08 12:40   ` Chris Wilson
2019-05-08 14:00     ` Mika Kuoppala
2019-05-08 14:10       ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abd68952-c310-3cfd-d00f-4a209ccbdb21@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.