drm/i915: Close race between processing unpin task and queueing the flip
authorChris Wilson <chris@chris-wilson.co.uk>
Mon, 3 Dec 2012 11:36:30 +0000 (11:36 +0000)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Thu, 6 Dec 2012 13:09:37 +0000 (14:09 +0100)
commite7d841ca03b7ab668620045cd7b428eda9f41601
tree513a8adda0a306e3e8c4b10d27f31992ed28f6b6
parentebf69cb8331d7336e4bcd442a2ca69bb61739a58
drm/i915: Close race between processing unpin task and queueing the flip

Before queuing the flip but crucially after attaching the unpin-work to
the crtc, we continue to setup the unpin-work. However, should the
hardware fire early, we see the connected unpin-work and queue the task.
The task then promptly runs and unpins the fb before we finish taking
the required references or even pinning it... Havoc.

To close the race, we use the flip-pending atomic to indicate when the
flip is finally setup and enqueued. So during the flip-done processing,
we can check more accurately whether the flip was expected.

v2: Add the appropriate mb() to ensure that the writes to the page-flip
worker are complete prior to marking it active and emitting the MI_FLIP.
On the read side, the mb should be enforced by the spinlocks.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: Review the barriers a bit, we need a write barrier both
before and after updating ->pending. Similarly we need a read barrier
in the interrupt handler both before and after reading ->pending. With
well-ordered irqs only one barrier in each place should be required,
but since this patch explicitly sets out to combat spurious interrupts
with is staged activation of the unpin work we need to go full-bore on
the barriers, too. Discussed with Chris Wilson on irc and changes
acked by him.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/i915_debugfs.c
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_drv.h