summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2013-08-15 00:02:37 +0200
committerChanho Park <chanho61.park@samsung.com>2014-11-21 19:13:43 +0900
commit0458c0546cbed4a1bcaa9eec8b69b8216ae73416 (patch)
tree6812be7c6f456eee7b37e0fc02fcdb110130da3d /include
parentad88c30ff4a1eb62f23dd5b5ff99f3ac576ae20e (diff)
downloadlinux-3.10-0458c0546cbed4a1bcaa9eec8b69b8216ae73416.tar.gz
linux-3.10-0458c0546cbed4a1bcaa9eec8b69b8216ae73416.tar.bz2
linux-3.10-0458c0546cbed4a1bcaa9eec8b69b8216ae73416.zip
drm/gem: fix up flink name create race
This is the 2nd attempt, I've always been a bit dissatisified with the tricky nature of the first one: http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html The issue is that the flink ioctl can race with calling gem_close on the last gem handle. In that case we'll end up with a zero handle count, but an flink name (and it's corresponding reference). Which results in a neat space leak. In my first attempt I've solved this by rechecking the handle count. But fundamentally the issue is that ->handle_count isn't your usual refcount - it can be resurrected from 0 among other things. For those special beasts atomic_t often suggest way more ordering that it actually guarantees. To prevent being tricked by those hairy semantics take the easy way out and simply protect the handle with the existing dev->object_name_lock. With that change implemented it's dead easy to fix the flink vs. gem close reace: When we try to create the name we simply have to check whether there's still officially a gem handle around and if not refuse to create the flink name. Since the handle count decrement and flink name destruction is now also protected by that lock the reace is gone and we can't ever leak the flink reference again. Outside of the drm core only the exynos driver looks at the handle count, and tbh I have no idea why (it's just for debug dmesg output luckily). I've considered inlining the drm_gem_object_handle_free, but I plan to add more name-like things (like the exported dma_buf) to this scheme, so it's clearer to leave the handle freeing in its own function. This is exercised by the new gem_flink_race i-g-t testcase, which on my snb leaks gem objects at a rate of roughly 1k objects/s. v2: Fix up the error path handling in handle_create and make it more robust by simply calling object_handle_unreference. v3: Fix up the handle_unreference logic bug - atomic_dec_and_test retursn 1 for 0. Oops. v4: Squash in inlining of drm_gem_object_handle_reference as suggested by Dave Airlie and add a note that we now have a testcase. Cc: Dave Airlie <airlied@gmail.com> Cc: Inki Dae <inki.dae@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'include')
-rw-r--r--include/drm/drmP.h19
1 files changed, 10 insertions, 9 deletions
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2a72a8eec69..4b854a899fa 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -637,8 +637,16 @@ struct drm_gem_object {
/** Reference count of this object */
struct kref refcount;
- /** Handle count of this object. Each handle also holds a reference */
- atomic_t handle_count; /* number of handles on this object */
+ /**
+ * handle_count - gem file_priv handle count of this object
+ *
+ * Each handle also holds a reference. Note that when the handle_count
+ * drops to 0 any global names (e.g. the id in the flink namespace) will
+ * be cleared.
+ *
+ * Protected by dev->object_name_lock.
+ * */
+ unsigned handle_count;
/** Related drm device */
struct drm_device *dev;
@@ -1711,13 +1719,6 @@ int drm_gem_handle_create(struct drm_file *file_priv,
u32 *handlep);
int drm_gem_handle_delete(struct drm_file *filp, u32 handle);
-static inline void
-drm_gem_object_handle_reference(struct drm_gem_object *obj)
-{
- drm_gem_object_reference(obj);
- atomic_inc(&obj->handle_count);
-}
-
void drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj);
void drm_gem_free_mmap_offset(struct drm_gem_object *obj);