From: Oleksandr Andrushchenko Date: Fri, 27 Jan 2017 07:04:25 +0000 (+0200) Subject: drm/prime: Clarify DMA-BUF/GEM Object lifetime X-Git-Tag: v4.11-rc1~83^2~32^2~11 X-Git-Url: https://git.karo-electronics.de/?a=commitdiff_plain;h=fa4c1de4a1aeeb0ef4dca692c779abbcc6c4960f;p=karo-tx-linux.git 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 Cc: Dave Airlie Cc: Daniel Vetter Signed-off-by: Oleksandr Andrushchenko [danvet: Minor spelling fixes, and some clarification of the 2nd paragraph.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1485500665-27690-1-git-send-email-andr2000@gmail.com --- diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 485e558d6661..25aa4558f1b5 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -40,8 +40,11 @@ * 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 * first calls .prime_export and stores the exporting GEM object in - * the dma_buf priv. This reference is released when the dma_buf - * object goes away in the driver .release function. + * the dma_buf priv. This reference needs to be released when the + * 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 * dma_buf (which in turn holds a ref to the exporting GEM object). @@ -51,6 +54,16 @@ * when the imported object is destroyed, we remove the attachment * 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 * (avoiding loops): importing_gem -> dmabuf -> exporting_gem *