--- /dev/null
+From da168d81b44898404d281d5dbe70154ab5f117c1 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Tue, 23 Jun 2015 11:34:21 +0200
+Subject: drm: Reject DRI1 hw lock ioctl functions for kms drivers
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit da168d81b44898404d281d5dbe70154ab5f117c1 upstream.
+
+I've done some extensive history digging across libdrm, mesa and
+xf86-video-{intel,nouveau,ati}. The only potential user of this with
+kms drivers I could find was ttmtest, which once used drmGetLock
+still. But that mistake was quickly fixed up. Even the intel xvmc
+library (which otherwise was really good with using dri1 stuff in kms
+mode) managed to never take the hw lock for dri2 (and hence kms).
+
+Hence it should be save to unconditionally disallow this.
+
+Cc: Peter Antoine <peter.antoine@intel.com>
+Reviewed-by: Peter Antoine <peter.antoine@intel.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_lock.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/gpu/drm/drm_lock.c
++++ b/drivers/gpu/drm/drm_lock.c
+@@ -58,6 +58,9 @@ int drm_lock(struct drm_device *dev, voi
+ struct drm_master *master = file_priv->master;
+ int ret = 0;
+
++ if (drm_core_check_feature(dev, DRIVER_MODESET))
++ return -EINVAL;
++
+ ++file_priv->lock_count;
+
+ if (lock->context == DRM_KERNEL_CONTEXT) {
+@@ -151,6 +154,9 @@ int drm_unlock(struct drm_device *dev, v
+ struct drm_lock *lock = data;
+ struct drm_master *master = file_priv->master;
+
++ if (drm_core_check_feature(dev, DRIVER_MODESET))
++ return -EINVAL;
++
+ if (lock->context == DRM_KERNEL_CONTEXT) {
+ DRM_ERROR("Process %d using kernel context %d\n",
+ task_pid_nr(current), lock->context);