@@ -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 refernce 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,15 @@
* 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, e.g. when
+ * userspace closes both handles to the imported (fd_to_handle_ioctl)
+ * and exported (handle_to_fd_ioctl) dma_buf and closes the corresponding
+ * file descriptor (handle_to_fd), then dma_buf gets destroyed.
+ * This can also happen as a part of the clean up procedure in the
+ * driver .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
*