iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

drm/gem: Document that handle_create must be the last step

Browse Source 
It published the gem object to userspace, by that point other threads
can guess the id and start using it. And gem IDs are _very_ easy to
guess (it's just an idr).

Since gem objects is the only thing we allow drivers to create
themselves (all the kms/prime/syncobj stuff is handled by the core) no
other functions seem to be in need of this clarification.

Motivated by reviewing the xen-front kms driver.

Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180322080233.17266-1-daniel.vetter@ffwll.ch
This commit is contained in:
Daniel Vetter 2018-03-22 09:02:33 +01:00
parent 3f07f28b97
commit 3903117609
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
drivers/gpu/drm/drm_gem.c
View File

@ -436,9 +436,12 @@ err_unref:
* @obj: object to register
* @handlep: pionter to return the created handle to the caller
*
* Create a handle for this object. This adds a handle reference
* to the object, which includes a regular reference count. Callers
* will likely want to dereference the object afterwards.
* Create a handle for this object. This adds a handle reference to the object,
* which includes a regular reference count. Callers will likely want to
* dereference the object afterwards.
*
* Since this publishes @obj to userspace it must be fully set up by this point,
* drivers must call this last in their buffer object creation callbacks.
*/
int drm_gem_handle_create(struct drm_file *file_priv,
struct drm_gem_object *obj,