If userspace does stupid things and closes the last GEM handle while calling the flink ioctl, we might end up with and object with obj->handle_count == 0, but an flink name lying around.
And that flink name must hold a reference on the underlying gem objects, leading to a neat resource leak (because we only reap these flink names when obj->handle_count drops to zero).
Noticed while fixing up the prime import/export locking, which had similar issues.
Signed-Off-by: Daniel Vetter daniel.vetter@ffwll.ch --- drivers/gpu/drm/drm_gem.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index a9e169a..6aa30b8 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -298,6 +298,11 @@ again: } }
+ /* Check whether someone sneaky dropped the last userspace gem handle, + * clean up the mess if so. */ + if (atomic_read(&obj->handle_count) == 0) + drm_gem_object_handle_free(obj); + return 0; } EXPORT_SYMBOL(drm_gem_handle_create);