diff options
author | Daniel Vetter | 2013-12-10 13:20:59 +0100 |
---|---|---|
committer | Daniel Vetter | 2013-12-11 14:25:58 +0100 |
commit | 6c719faca2aceca72f1bf5b1645c1734ed3e9447 (patch) | |
tree | eaabeca4f3923e4dcb3c473e3943dd7e9605a344 /drivers/gpu/drm/drm_context.c | |
parent | drm/i915: Repeat eviction search after idling the GPU (diff) | |
download | kernel-qcow2-linux-6c719faca2aceca72f1bf5b1645c1734ed3e9447.tar.gz kernel-qcow2-linux-6c719faca2aceca72f1bf5b1645c1734ed3e9447.tar.xz kernel-qcow2-linux-6c719faca2aceca72f1bf5b1645c1734ed3e9447.zip |
drm/i915: don't update the dri1 breadcrumb with modesetting
The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.
Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.
Note that the race is fairly easy to hit since we call the breadcrumb
function for any interrupt. So the vblank interrupt (which usually
keeps going for a bit) is enough. But even if we'd block this and only
update the breadcrumb for user interrupts from the CS we could hit
this race with kms/gem userspace: If a non-master is waiting somewhere
(and hence has interrupts enabled) and the master closes its fd
(probably due to crashing).
v2: Add a code comment to explain why fixing this for real isn't
really worth it. Also improve the commit message a bit.
v3: Fix the spelling in the comment.
Reported-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Cc: stable@vger.kernel.org
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/drm_context.c')
0 files changed, 0 insertions, 0 deletions