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
next prev parent 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