[PATCH v5 2/3] dma-buf: add DMA_BUF_SET_NAME ioctls

Chris Wilson chris at chris-wilson.co.uk
Fri Jul 26 08:37:06 UTC 2019


Quoting Chenbo Feng (2019-06-13 23:34:07)
> From: Greg Hackmann <ghackmann at google.com>
> 
> This patch adds complimentary DMA_BUF_SET_NAME  ioctls, which lets
> userspace processes attach a free-form name to each buffer.
> 
> This information can be extremely helpful for tracking and accounting
> shared buffers.  For example, on Android, we know what each buffer will
> be used for at allocation time: GL, multimedia, camera, etc.  The
> userspace allocator can use DMA_BUF_SET_NAME to associate that
> information with the buffer, so we can later give developers a
> breakdown of how much memory they're allocating for graphics, camera,
> etc.

The name was never freed...
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d56993238501..0106b96da585 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -104,6 +104,8 @@ static int dma_buf_release(struct inode *inode, struct file *file)
        list_del(&dmabuf->list_node);
        mutex_unlock(&db_list.lock);

+       kfree(dmabuf->name);
+
        if (dmabuf->resv == (struct reservation_object *)&dmabuf[1])
                reservation_object_fini(dmabuf->resv);

This trusts that access to the name via the fs is serialised by the
refcount.

It would have been great if the inode would only be allocated for a
named dmabuf, but I expect that requires replacing struct file after it
is exposed (but maybe a struct file can be moved between fs?).
-Chris


More information about the dri-devel mailing list