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