Commit fa4c1de4 authored by Oleksandr Andrushchenko's avatar Oleksandr Andrushchenko Committed by Daniel Vetter

drm/prime: Clarify DMA-BUF/GEM Object lifetime

From the description of the "DMA-BUF/GEM Object references
and lifetime overview" it is not clear when exactly
dma_buf gets destroyed and memory freed: only driver
.release function mentioned which makes confusion on the
real buffer's lifetime.

Add more description so all the paths are covered.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
[danvet: Minor spelling fixes, and some clarification of the 2nd
paragraph.]
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1485500665-27690-1-git-send-email-andr2000@gmail.com
parent 239ac65f
...@@ -40,8 +40,11 @@ ...@@ -40,8 +40,11 @@
* On the export the dma_buf holds a reference to the exporting GEM * On the export the dma_buf holds a reference to the exporting GEM
* object. It takes this reference in handle_to_fd_ioctl, when it * object. It takes this reference in handle_to_fd_ioctl, when it
* first calls .prime_export and stores the exporting GEM object in * first calls .prime_export and stores the exporting GEM object in
* the dma_buf priv. This reference is released when the dma_buf * the dma_buf priv. This reference needs to be released when the
* object goes away in the driver .release function. * final reference to the &dma_buf itself is dropped and its
* &dma_buf_ops.release function is called. For GEM-based drivers,
* the dma_buf should be exported using drm_gem_dmabuf_export() and
* then released by drm_gem_dmabuf_release().
* *
* On the import the importing GEM object holds a reference to the * On the import the importing GEM object holds a reference to the
* dma_buf (which in turn holds a ref to the exporting GEM object). * dma_buf (which in turn holds a ref to the exporting GEM object).
...@@ -51,6 +54,16 @@ ...@@ -51,6 +54,16 @@
* when the imported object is destroyed, we remove the attachment * when the imported object is destroyed, we remove the attachment
* and drop the reference to the dma_buf. * and drop the reference to the dma_buf.
* *
* When all the references to the &dma_buf are dropped, i.e. when
* userspace has closed both handles to the imported GEM object (through the
* FD_TO_HANDLE IOCTL) and closed the file descriptor of the exported
* (through the HANDLE_TO_FD IOCTL) dma_buf, and all kernel-internal references
* are also gone, then the dma_buf gets destroyed. This can also happen as a
* part of the clean up procedure in the drm_release() function if userspace
* fails to properly clean up. Note that both the kernel and userspace (by
* keeeping the PRIME file descriptors open) can hold references onto a
* &dma_buf.
*
* Thus the chain of references always flows in one direction * Thus the chain of references always flows in one direction
* (avoiding loops): importing_gem -> dmabuf -> exporting_gem * (avoiding loops): importing_gem -> dmabuf -> exporting_gem
* *
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment