From: "Antoine, Peter" <peter.antoine@intel.com>
To: "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>
Cc: "Vetter, Daniel" <daniel.vetter@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 3/3] drm: Reject DRI1 hw lock ioctl functions for kms drivers
Date: Tue, 23 Jun 2015 13:16:35 +0000 [thread overview]
Message-ID: <1435065394.22268.3.camel@peterant-linux> (raw)
In-Reply-To: <1435052228-29710-3-git-send-email-daniel.vetter@ffwll.ch>
On Tue, 2015-06-23 at 11:37 +0200, Daniel Vetter wrote:
> 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>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/drm_lock.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
> index f861361a635e..4924d381b664 100644
> --- a/drivers/gpu/drm/drm_lock.c
> +++ b/drivers/gpu/drm/drm_lock.c
> @@ -61,6 +61,9 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
> 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) {
> @@ -153,6 +156,9 @@ int drm_legacy_unlock(struct drm_device *dev, void *data, struct drm_file *file_
> 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);
Reviewed-by: Peter Antoine <peter.antoine@intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-06-23 13:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 9:37 [PATCH 1/3] drm: Turn off Legacy Context Functions Daniel Vetter
2015-06-23 9:37 ` [PATCH 2/3] drm: Convert drm_legacy_ctxbitmap_init to void return type Daniel Vetter
2015-06-23 13:15 ` Antoine, Peter
2015-06-23 9:37 ` [PATCH 3/3] drm: Reject DRI1 hw lock ioctl functions for kms drivers Daniel Vetter
2015-06-23 13:16 ` Antoine, Peter [this message]
2015-06-23 13:14 ` [PATCH 1/3] drm: Turn off Legacy Context Functions Antoine, Peter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1435065394.22268.3.camel@peterant-linux \
--to=peter.antoine@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.