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

 * 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).

 * 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

 *