Commit 49fd0d61 authored by Daniel Vetter's avatar Daniel Vetter Committed by Greg Kroah-Hartman

drm: Reject DRI1 hw lock ioctl functions for kms drivers

commit da168d81 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: default avatarPeter Antoine <peter.antoine@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
parent 0d6ed498
......@@ -58,6 +58,9 @@ int drm_lock(struct drm_device *dev, void *data, struct drm_file *file_priv)
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) {
......@@ -150,6 +153,9 @@ int drm_unlock(struct drm_device *dev, void *data, struct drm_file *file_priv)
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);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment