All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Herrmann <dh.herrmann@gmail.com>
To: dri-devel@lists.freedesktop.org
Subject: [PATCH 5/5] drm: allocate kernel mode-object IDs in cyclic fashion
Date: Wed,  9 Sep 2015 14:21:33 +0200	[thread overview]
Message-ID: <1441801293-1440-6-git-send-email-dh.herrmann@gmail.com> (raw)
In-Reply-To: <1441801293-1440-1-git-send-email-dh.herrmann@gmail.com>

Now that we support connector hotplugging, user-space might see
mode-object IDs coming and going asynchronously. Therefore, we must make
sure to not re-use object IDs, so to not confuse user-space and introduce
races. Therefore, all kernel-allocated objects will no longer recycle
IDs. Instead, we use the cyclic idr allocator (which performs still fine
for reasonable allocation schemes).

However, for user-space allocated objects like framebuffers, we don't
want to risk allowing malicious users to screw with the ID space.
Furthermore, those objects happen to not be subject to ID hotplug races,
as they're allocated and freed explicitly. Hence, we still recycle IDs
for these objects (which are just framebuffers so far).

For atomic-modesetting, objects are looked up by the kernel without
specifying an object-type. Hence, we have a theoretical race where a
framebuffer recycles a previous connector ID. However, user-allocated
objects are never returned by drm_mode_object_find() (as they need
separate ref-count handling), so this race cannot happen with the
currently available objects. Even if we add ref-counting to other
objects, all we need to make sure is to never lookup user-controlled
objects with the same function as kernel-controlled objects, but not
specifying the type. This sounds highly unlikely to happen ever, so we
should be safe, anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
---
 drivers/gpu/drm/drm_crtc.c | 37 ++++++++++++++++++++++++++++++++-----
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 33d877c..fd8a2e2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -269,18 +269,42 @@ const char *drm_get_format_name(uint32_t format)
 EXPORT_SYMBOL(drm_get_format_name);
 
 /*
+ * Flags for drm_mode_object_get_reg():
+ * DRM_MODE_OBJECT_ID_UNLINKED:	Allocate the object ID, but do not store the
+ * 				object pointer. Hence, the object is not
+ * 				registered but needs to be inserted manually.
+ * 				This must be used for hotplugged objects.
+ * DRM_MODE_OBJECT_ID_RECYCLE:	Allow recycling previously allocated IDs. If
+ * 				not set, the IDs space is allocated in a cyclic
+ * 				fashion. This should be the default for all
+ * 				kernel allocated objects, to not confuse
+ * 				user-space on hotplug. This must not be used
+ * 				for user-allocated objects, though.
+ */
+enum {
+	DRM_MODE_OBJECT_ID_UNLINKED		= (1U << 0),
+	DRM_MODE_OBJECT_ID_RECYCLE			= (1U << 1),
+};
+
+/*
  * Internal function to assign a slot in the object idr and optionally
  * register the object into the idr.
  */
 static int drm_mode_object_get_reg(struct drm_device *dev,
 				   struct drm_mode_object *obj,
 				   uint32_t obj_type,
-				   bool register_obj)
+				   unsigned int flags)
 {
+	void *ptr = (flags & DRM_MODE_OBJECT_ID_UNLINKED) ? NULL : obj;
 	int ret;
 
 	mutex_lock(&dev->mode_config.idr_mutex);
-	ret = idr_alloc(&dev->mode_config.crtc_idr, register_obj ? obj : NULL, 1, 0, GFP_KERNEL);
+	if (flags & DRM_MODE_OBJECT_ID_RECYCLE)
+		ret = idr_alloc(&dev->mode_config.crtc_idr, ptr, 1, 0,
+				GFP_KERNEL);
+	else
+		ret = idr_alloc_cyclic(&dev->mode_config.crtc_idr, ptr, 1, 0,
+				       GFP_KERNEL);
 	if (ret >= 0) {
 		/*
 		 * Set up the object linking under the protection of the idr
@@ -312,7 +336,7 @@ static int drm_mode_object_get_reg(struct drm_device *dev,
 int drm_mode_object_get(struct drm_device *dev,
 			struct drm_mode_object *obj, uint32_t obj_type)
 {
-	return drm_mode_object_get_reg(dev, obj, obj_type, true);
+	return drm_mode_object_get_reg(dev, obj, obj_type, 0);
 }
 
 static void drm_mode_object_register(struct drm_device *dev,
@@ -414,7 +438,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb,
 	fb->dev = dev;
 	fb->funcs = funcs;
 
-	ret = drm_mode_object_get(dev, &fb->base, DRM_MODE_OBJECT_FB);
+	ret = drm_mode_object_get_reg(dev, &fb->base, DRM_MODE_OBJECT_FB,
+				      DRM_MODE_OBJECT_ID_RECYCLE);
 	if (ret)
 		goto out;
 
@@ -872,7 +897,9 @@ int drm_connector_init(struct drm_device *dev,
 
 	drm_modeset_lock_all(dev);
 
-	ret = drm_mode_object_get_reg(dev, &connector->base, DRM_MODE_OBJECT_CONNECTOR, false);
+	ret = drm_mode_object_get_reg(dev, &connector->base,
+				      DRM_MODE_OBJECT_CONNECTOR,
+				      DRM_MODE_OBJECT_ID_UNLINKED);
 	if (ret)
 		goto out_unlock;
 
-- 
2.5.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2015-09-09 12:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09 12:21 [PATCH 0/5] DRM Cleanups David Herrmann
2015-09-09 12:21 ` [PATCH 1/5] drm: simplify drm_sysfs_destroy() via IS_ERR_OR_NULL() David Herrmann
2015-09-09 12:21 ` [PATCH 2/5] drm: move drm_class into drm_sysfs.c David Herrmann
2015-09-09 13:16   ` Daniel Vetter
2015-09-09 12:21 ` [PATCH 3/5] drm: cleanup drm_core_{init,exit}() David Herrmann
2015-09-09 13:11   ` Daniel Vetter
2015-09-09 13:19     ` David Herrmann
2015-09-09 12:21 ` [PATCH 4/5] drm: drop obsolete drm_core.h David Herrmann
2015-09-09 12:21 ` David Herrmann [this message]
2015-09-09 13:03   ` [PATCH 5/5] drm: allocate kernel mode-object IDs in cyclic fashion Daniel Vetter
2015-09-11  9:47     ` David Herrmann
2015-09-11 12:14       ` Daniel Vetter

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=1441801293-1440-6-git-send-email-dh.herrmann@gmail.com \
    --to=dh.herrmann@gmail.com \
    --cc=dri-devel@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.