On Wed, Feb 19, 2014 at 02:40:41PM +0100, Thomas Hellstrom wrote:
Like for render-nodes, there is no point in maintaining the master concept for control nodes, so set the struct drm_file::master pointer to NULL.
At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always allowed when called through the control node. Previously the caller also needed to be master.
Signed-off-by: Thomas Hellstrom thellstrom@vmware.com
drivers/gpu/drm/drm_drv.c | 5 +++-- drivers/gpu/drm/drm_fops.c | 5 +++-- include/drm/drmP.h | 5 +++++ 3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 345be03..42af8bd 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -355,8 +355,9 @@ long drm_ioctl(struct file *filp, retcode = -EINVAL; } else if (((ioctl->flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)) || ((ioctl->flags & DRM_AUTH) && !drm_is_render_client(file_priv) && !file_priv->authenticated) ||
((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
(!(ioctl->flags & DRM_CONTROL_ALLOW) && (file_priv->minor->type == DRM_MINOR_CONTROL)) ||
(((ioctl->flags & DRM_MASTER) && !file_priv->is_master) &&
!(drm_is_control(file_priv) && (ioctl->flags & DRM_CONTROL_ALLOW))) ||
(!(ioctl->flags & DRM_RENDER_ALLOW) && drm_is_render_client(file_priv))) {(!(ioctl->flags & DRM_CONTROL_ALLOW) && drm_is_control(file_priv)) ||
This is hideous to review ;-) I think it would be really good to extract this entire condition into a drm_check_ioctl_acces(ioctl, file_priv) helper and untangle all the different cases a bit by splitting it up into if checks with individual return false/true; statements.
With that bit of polish for the next reviewer's sanity applied both patches are Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch
I guess with this change we could move the master pointer from drm_minor to drm_device, which would make it really clear that there's only ever one master per device. But that's one giant sed job, so meh ;-)
One thing I'm unsure about is whether we want/need to have the master concept on the control node, too. logind uses set/dropmaster as a kms-specific revoke support, so if we ever want to switch to using control nodes for display servers we'd need to shuffle this a bit again.
Otoh no one is using control nodes for real afaik, so we likely need some interface polishing anyway. And for non-root display servers we can block out all the awful legacy drm ioctls easily, so just keeping on using legacy nodes isn't a security issue for that use-case.
Cheers, Daniel
retcode = -EACCES;
} else { diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 7f2af9a..08a3196 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -259,7 +259,8 @@ static int drm_open_helper(struct inode *inode, struct file *filp, /* if there is no current master make this fd it, but do not create * any master object for render clients */ mutex_lock(&dev->struct_mutex);
- if (!priv->minor->master && !drm_is_render_client(priv)) {
- if (!priv->minor->master && !drm_is_render_client(priv) &&
/* create a new master */ priv->minor->master = drm_master_create(priv->minor); if (!priv->minor->master) {!drm_is_control(priv)) {
@@ -297,7 +298,7 @@ static int drm_open_helper(struct inode *inode, struct file *filp, goto out_close; } }
- } else if (!drm_is_render_client(priv)) {
- } else if (!drm_is_render_client(priv) && !drm_is_control(priv)) { /* get a reference to the master */ priv->master = drm_master_get(priv->minor->master); }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 04a7f31..ff68e26 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1246,6 +1246,11 @@ static inline bool drm_is_render_client(struct drm_file *file_priv) return file_priv->minor->type == DRM_MINOR_RENDER; }
+static inline bool drm_is_control(struct drm_file *file_priv) +{
- return file_priv->minor->type == DRM_MINOR_CONTROL;
+}
/******************************************************************/ /** \name Internal function definitions */ /*@{*/ -- 1.7.10.4 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel