drm/i915: hold dev->struct_mutex and DRM lock during vblank ring operations

To synchronize clip lists with the X server, the DRM lock must be held while
looking at drawable clip lists. To synchronize with other ring access, the
ring mutex must be held while inserting commands into the ring.  Failure to
do the first resulted in easy visual corruption when moving windows, and the
second could have corrupted the ring with DRI2.

Grabbing the DRM lock involves using the DRM tasklet mechanism, grabbing the
ring mutex means potentially sleeping. Deal with both of these by always
running the tasklet from a work handler.

Also, protect from clip list changes since the vblank request was queued by
making sure the window has at least one rectangle while looking inside,
preventing oopses .

Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

1 files changed, 2 insertions, 0 deletions

diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index a4caf95..888159e 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -232,6 +232,7 @@ int drm_lock_take(struct drm_lock_data *lock_data,
 	}
 	return 0;
 }
+EXPORT_SYMBOL(drm_lock_take);
 
 /**
  * This takes a lock forcibly and hands it to context.	Should ONLY be used
@@ -299,6 +300,7 @@ int drm_lock_free(struct drm_lock_data *lock_data, unsigned int context)
 	wake_up_interruptible(&lock_data->lock_queue);
 	return 0;
 }
+EXPORT_SYMBOL(drm_lock_free);
 
 /**
  * If we get here, it means that the process has called DRM_IOCTL_LOCK