public inbox for intel-gfx@lists.freedesktop.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 3/6] drm/i915/breadcrumbs: Update bottom-half before marking as complete
Date: Wed, 15 Mar 2017 19:30:11 +0000	[thread overview]
Message-ID: <f166c0e1-213d-77bd-575c-a797067a67ac@linux.intel.com> (raw)
In-Reply-To: <20170315191059.GK2118@nuc-i3427.alporthouse.com>


On 15/03/2017 19:10, Chris Wilson wrote:
> On Wed, Mar 15, 2017 at 06:58:27PM +0000, Tvrtko Ursulin wrote:
>>
>> On 15/03/2017 14:01, Chris Wilson wrote:
>>> When adding a new request to the breadcrumb rbtree, we mark all those
>>> requests inside the rbtree that are already completed as complete. This
>>> wakes those waiters up and allows them to skip the spinlock before
>>> returning to userspace. If one of those is the current bottom-half, it
>>> may then overwrite intel_wait as the interrupt handler dereferences it.
>>
>> Last sentence sounds suspicious. The interrupts are disabled when
>> this runs and locking is in place. And since the fix is to move the
>> "completed" block after the "first", I wonder what can get
>> overwritten by who?
>>
>> Oh.. __intel_breadcrumbs_finish. But how does re-ordering help?
>> Shouldn't the fix be to skip the bottom-half assignment if the
>> "complete" loop has processed the waiter getting added?
>
> Thread A runs intel_engine_add_wait, marks an earlier waiter complete
> and wakes up thread B. Thread C is processing the interrupt and grabs
> the irq_wait. However, thread B sees that is is complete and exits
> i915_aait_request() invalidating the irq_wait as it is being used by
> thread C.
>
> Moving the irq_wait update before we wakeup thread B, ensures that
> thread C has a valid irq_wait.

As discussed on the IRC, it is not that the exiting waiter explicitly 
destroys the intel_wait state, but it happens implicitly because the 
struct is on the waiter's stack. I was misled by the short-circuit in 
intel_engine_remove_wait to think commit message was incorrect so I 
suggest describing the stack situation explicitly in the commit.

With a line added to do so:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

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

  reply	other threads:[~2017-03-15 19:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-15 14:01 [PATCH 1/6] drm/i915/breadcrumbs: Use booleans for intel_breadcrumbs_busy() Chris Wilson
2017-03-15 14:01 ` [PATCH 2/6] drm/i915/breadcrumbs: Assert that irqs are disabled as we update the bottom-half Chris Wilson
2017-03-15 18:20   ` Tvrtko Ursulin
2017-03-15 18:32     ` Chris Wilson
2017-03-15 19:01       ` Tvrtko Ursulin
2017-03-15 14:01 ` [PATCH 3/6] drm/i915/breadcrumbs: Update bottom-half before marking as complete Chris Wilson
2017-03-15 18:58   ` Tvrtko Ursulin
2017-03-15 19:10     ` Chris Wilson
2017-03-15 19:30       ` Tvrtko Ursulin [this message]
2017-03-15 14:01 ` [PATCH 4/6] drm/i915/breadcrumbs: Disable interrupt bottom-half first on idling Chris Wilson
2017-03-15 19:33   ` Tvrtko Ursulin
2017-03-15 14:01 ` [PATCH 5/6] drm/i915/breadcrumbs: Assert that we do not shortcut the current bottom-half Chris Wilson
2017-03-15 19:40   ` Tvrtko Ursulin
2017-03-15 14:01 ` [PATCH 6/6] drm/i915: Only attempt to signal the request once from the interrupt handler Chris Wilson
2017-03-15 19:47   ` Tvrtko Ursulin
2017-03-15 20:05     ` Chris Wilson
2017-03-15 20:09       ` Tvrtko Ursulin
2017-03-15 14:52 ` ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/breadcrumbs: Use booleans for intel_breadcrumbs_busy() Patchwork
2017-03-15 18:03 ` [PATCH 1/6] " Tvrtko Ursulin

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=f166c0e1-213d-77bd-575c-a797067a67ac@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox