dma-buf: Add debugfs support

Message ID 1355477817-5750-1-git-send-email-sumit.semwal@ti.com
State Superseded
Headers show

Commit Message

Sumit Semwal Dec. 14, 2012, 9:36 a.m.
From: Sumit Semwal <sumit.semwal@linaro.org>

Add debugfs support to make it easier to print debug information
about the dma-buf buffers.

Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
---
 drivers/base/dma-buf.c  |  149 +++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/dma-buf.h |    6 +-
 2 files changed, 154 insertions(+), 1 deletion(-)

Comments

Daniel Vetter Dec. 14, 2012, 10:29 a.m. | #1
On Fri, Dec 14, 2012 at 10:36 AM,  <sumit.semwal@ti.com> wrote:
> From: Sumit Semwal <sumit.semwal@linaro.org>
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>

Looks line, only nitpick is that we have no idea who exported a given
buffer. So what about adding a new dma_buf_export_named which takes a
char * to identify the exporter, and then add a bit of cpp magic like
this:

#define dma_buf_export(args) dma_buf_export_named(args, stringify(__FILE))

At least for drm drivers using the prime helpers this should add the
file of the exporting driver, so would be good enough to identify the
exporter. Or we could add a dma_buf_export_dev which has a struct
device * as additional argument ... Otoh that wouldn't really work for
exporting dma_bufs from ION, so maybe a const char * is better.
-Daniel

> ---
>  drivers/base/dma-buf.c  |  149 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/dma-buf.h |    6 +-
>  2 files changed, 154 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index a3f79c4..49fcf0f 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -27,9 +27,18 @@
>  #include <linux/dma-buf.h>
>  #include <linux/anon_inodes.h>
>  #include <linux/export.h>
> +#include <linux/debugfs.h>
> +#include <linux/seq_file.h>
>
>  static inline int is_dma_buf_file(struct file *);
>
> +struct dma_buf_list {
> +       struct list_head head;
> +       struct mutex lock;
> +};
> +
> +static struct dma_buf_list db_list;
> +
>  static int dma_buf_release(struct inode *inode, struct file *file)
>  {
>         struct dma_buf *dmabuf;
> @@ -40,6 +49,11 @@ static int dma_buf_release(struct inode *inode, struct file *file)
>         dmabuf = file->private_data;
>
>         dmabuf->ops->release(dmabuf);
> +
> +       mutex_lock(&db_list.lock);
> +       list_del(&dmabuf->list_node);
> +       mutex_unlock(&db_list.lock);
> +
>         kfree(dmabuf);
>         return 0;
>  }
> @@ -120,6 +134,10 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
>         mutex_init(&dmabuf->lock);
>         INIT_LIST_HEAD(&dmabuf->attachments);
>
> +       mutex_lock(&db_list.lock);
> +       list_add(&dmabuf->list_node, &db_list.head);
> +       mutex_unlock(&db_list.lock);
> +
>         return dmabuf;
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_export);
> @@ -505,3 +523,134 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
>                 dmabuf->ops->vunmap(dmabuf, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
> +
> +static int dma_buf_init_debugfs(void);
> +static void dma_buf_uninit_debugfs(void);
> +
> +static void __init dma_buf_init(void)
> +{
> +       mutex_init(&db_list.lock);
> +       INIT_LIST_HEAD(&db_list.head);
> +       dma_buf_init_debugfs();
> +}
> +
> +static void __exit dma_buf_deinit(void)
> +{
> +       dma_buf_uninit_debugfs();
> +}
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int dma_buf_describe(struct seq_file *s)
> +{
> +       int ret;
> +       struct dma_buf *buf_obj;
> +       struct dma_buf_attachment *attach_obj;
> +       int count = 0, attach_count;
> +       size_t size = 0;
> +
> +       ret = mutex_lock_interruptible(&db_list.lock);
> +
> +       if (ret)
> +               return ret;
> +
> +       seq_printf(s, "\nDma-buf Objects:\n");
> +       seq_printf(s, "\tsize\tflags\tmode\tcount\n");
> +
> +       list_for_each_entry(buf_obj, &db_list.head, list_node) {
> +               seq_printf(s, "\t");
> +
> +               seq_printf(s, "%08zu\t%08x\t%08x\t%08d\n",
> +                               buf_obj->size, buf_obj->file->f_flags,
> +                               buf_obj->file->f_mode,
> +                               buf_obj->file->f_count.counter);
> +
> +               seq_printf(s, "\t\tAttached Devices:\n");
> +               attach_count = 0;
> +
> +               list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
> +                       seq_printf(s, "\t\t");
> +
> +                       seq_printf(s, "%s\n", attach_obj->dev->init_name);
> +                       attach_count++;
> +               }
> +
> +               seq_printf(s, "\n\t\tTotal %d devices attached\n",
> +                               attach_count);
> +
> +               count++;
> +               size += buf_obj->size;
> +       }
> +
> +       seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
> +
> +       mutex_unlock(&db_list.lock);
> +       return 0;
> +}
> +
> +static int dma_buf_show(struct seq_file *s, void *unused)
> +{
> +       void (*func)(struct seq_file *) = s->private;
> +       func(s);
> +       return 0;
> +}
> +
> +static int dma_buf_debug_open(struct inode *inode, struct file *file)
> +{
> +       return single_open(file, dma_buf_show, inode->i_private);
> +}
> +
> +static const struct file_operations dma_buf_debug_fops = {
> +       .open           = dma_buf_debug_open,
> +       .read           = seq_read,
> +       .llseek         = seq_lseek,
> +       .release        = single_release,
> +};
> +
> +static struct dentry *dma_buf_debugfs_dir;
> +
> +static int dma_buf_init_debugfs(void)
> +{
> +       int err = 0;
> +       dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL);
> +       if (IS_ERR(dma_buf_debugfs_dir)) {
> +               err = PTR_ERR(dma_buf_debugfs_dir);
> +               dma_buf_debugfs_dir = NULL;
> +               return err;
> +       }
> +
> +       err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe);
> +
> +       if (err)
> +               pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
> +
> +       return err;
> +}
> +
> +static void dma_buf_uninit_debugfs(void)
> +{
> +       if (dma_buf_debugfs_dir)
> +               debugfs_remove_recursive(dma_buf_debugfs_dir);
> +}
> +
> +int dma_buf_debugfs_create_file(const char *name,
> +                               int (*write)(struct seq_file *))
> +{
> +       struct dentry *d;
> +
> +       d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir,
> +                       write, &dma_buf_debug_fops);
> +
> +       if (IS_ERR(d))
> +               return PTR_ERR(d);
> +
> +       return 0;
> +}
> +#else
> +static inline int dma_buf_init_debugfs(void)
> +{
> +       return 0;
> +}
> +static inline void dma_buf_uninit_debugfs(void)
> +{
> +}
> +#endif
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index bd2e52c..160453f 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -112,6 +112,7 @@ struct dma_buf_ops {
>   * @file: file pointer used for sharing buffers across, and for refcounting.
>   * @attachments: list of dma_buf_attachment that denotes all devices attached.
>   * @ops: dma_buf_ops associated with this buffer object.
> + * @list_node: node for dma_buf accounting and debugging.
>   * @priv: exporter specific private data for this buffer object.
>   */
>  struct dma_buf {
> @@ -121,6 +122,8 @@ struct dma_buf {
>         const struct dma_buf_ops *ops;
>         /* mutex to serialize list manipulation and attach/detach */
>         struct mutex lock;
> +
> +       struct list_head list_node;
>         void *priv;
>  };
>
> @@ -183,5 +186,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
>                  unsigned long);
>  void *dma_buf_vmap(struct dma_buf *);
>  void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> -
> +int dma_buf_debugfs_create_file(const char *name,
> +                               int (*write)(struct seq_file *));
>  #endif /* __DMA_BUF_H__ */
> --
> 1.7.10.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Daniel Vetter Dec. 14, 2012, 10:34 a.m. | #2
Missed one ...

On Fri, Dec 14, 2012 at 10:36 AM,  <sumit.semwal@ti.com> wrote:
> +               list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
> +                       seq_printf(s, "\t\t");
> +
> +                       seq_printf(s, "%s\n", attach_obj->dev->init_name);
> +                       attach_count++;
> +               }

You need to hold dmabuf->lock while walking the attachment list.
-Daniel
Maarten Lankhorst Dec. 14, 2012, 11:57 a.m. | #3
Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
> From: Sumit Semwal <sumit.semwal@linaro.org>
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
I like the idea, I don't know if it could be done in a free manner, but for bonus points
could we also have the dma-buf fd be obtainable that way from a debugfs entry?

Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.

Also I think the name of the device and process that exported the dma-buf would be useful
to have as well, even if in case of the device that would mean changing the api slightly to record it.

I was thinking of having a directory structure like this:

/sys/kernel/debug/dma_buf/stats

and then for each dma-buf:

/sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd
/sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments
/sys/kernel/debug/dma-buf/exporting_file.c/<number>-info

Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.

Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,

~Maarten
Rob Clark Dec. 14, 2012, 2:11 p.m. | #4
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
<m.b.lankhorst@gmail.com> wrote:
> Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
>> From: Sumit Semwal <sumit.semwal@linaro.org>
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
> I like the idea, I don't know if it could be done in a free manner, but for bonus points
> could we also have the dma-buf fd be obtainable that way from a debugfs entry?
>
> Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
>
> Also I think the name of the device and process that exported the dma-buf would be useful
> to have as well, even if in case of the device that would mean changing the api slightly to record it.
>
> I was thinking of having a directory structure like this:
>
> /sys/kernel/debug/dma_buf/stats
>
> and then for each dma-buf:
>
> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd
> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments
> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
>
> Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
>
> Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,

yeah.. but sort of back-door's the security benefits of an anonymous fd..

BR,
-R

> ~Maarten
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Maarten Lankhorst Dec. 14, 2012, 2:35 p.m. | #5
Op 14-12-12 15:11, Rob Clark schreef:
> On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
> <m.b.lankhorst@gmail.com> wrote:
>> Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
>>> From: Sumit Semwal <sumit.semwal@linaro.org>
>>>
>>> Add debugfs support to make it easier to print debug information
>>> about the dma-buf buffers.
>>>
>> I like the idea, I don't know if it could be done in a free manner, but for bonus points
>> could we also have the dma-buf fd be obtainable that way from a debugfs entry?
>>
>> Doing so would allow me to 'steal' a dma-buf from an existing mapping easily, and test against that.
>>
>> Also I think the name of the device and process that exported the dma-buf would be useful
>> to have as well, even if in case of the device that would mean changing the api slightly to record it.
>>
>> I was thinking of having a directory structure like this:
>>
>> /sys/kernel/debug/dma_buf/stats
>>
>> and then for each dma-buf:
>>
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
>>
>> Opening the fd file would give you back the original fd, or fail with -EIO if refcount was dropped to 0.
>>
>> Would something like this be doable? I don't know debugfs that well, but I don't see why it wouldn't be,
> yeah.. but sort of back-door's the security benefits of an anonymous fd..
>
> BR,
> -R
If you have access to debugfs you're root, so what stops you from stealing it through a ptrace?

~Maarten
Francesco Lavra Dec. 16, 2012, 4:56 p.m. | #6
Hi,

On 12/14/2012 10:36 AM, sumit.semwal@ti.com wrote:
> From: Sumit Semwal <sumit.semwal@linaro.org>
> 
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
> 
> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
> ---
>  drivers/base/dma-buf.c  |  149 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/dma-buf.h |    6 +-
>  2 files changed, 154 insertions(+), 1 deletion(-)
[...]
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index bd2e52c..160453f 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -112,6 +112,7 @@ struct dma_buf_ops {
>   * @file: file pointer used for sharing buffers across, and for refcounting.
>   * @attachments: list of dma_buf_attachment that denotes all devices attached.
>   * @ops: dma_buf_ops associated with this buffer object.
> + * @list_node: node for dma_buf accounting and debugging.
>   * @priv: exporter specific private data for this buffer object.
>   */
>  struct dma_buf {
> @@ -121,6 +122,8 @@ struct dma_buf {
>  	const struct dma_buf_ops *ops;
>  	/* mutex to serialize list manipulation and attach/detach */
>  	struct mutex lock;
> +
> +	struct list_head list_node;
>  	void *priv;
>  };
>  
> @@ -183,5 +186,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
>  		 unsigned long);
>  void *dma_buf_vmap(struct dma_buf *);
>  void dma_buf_vunmap(struct dma_buf *, void *vaddr);
> -
> +int dma_buf_debugfs_create_file(const char *name,
> +				int (*write)(struct seq_file *));

Why is this function declared in the public header file?

--
Francesco
Sumit Semwal Dec. 17, 2012, 8:55 a.m. | #7
Hi Maarten,

On 14 December 2012 17:27, Maarten Lankhorst <m.b.lankhorst@gmail.com>wrote:

> Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
> > From: Sumit Semwal <sumit.semwal@linaro.org>
> >
> > Add debugfs support to make it easier to print debug information
> > about the dma-buf buffers.
> >
> I like the idea, I don't know if it could be done in a free manner, but
> for bonus points
> could we also have the dma-buf fd be obtainable that way from a debugfs
> entry?
>
> Doing so would allow me to 'steal' a dma-buf from an existing mapping
> easily, and test against that.

Also I think the name of the device and process that exported the dma-buf
> would be useful
> to have as well, even if in case of the device that would mean changing
> the api slightly to record it.
>
> I was thinking of having a directory structure like this:
>
> /sys/kernel/debug/dma_buf/stats
>
> and then for each dma-buf:
>
> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd
> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments
> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
>
> Opening the fd file would give you back the original fd, or fail with -EIO
> if refcount was dropped to 0.
>
> Would something like this be doable? I don't know debugfs that well, but I
> don't see why it wouldn't be,
>
Let me think more about it, but I am inclined to add simple support first,
and then add more features to dma_buf debugfs as it grows.

I still would want to take Daniel's suggestion on dma_buf_export_named()
before I push this patch, so I guess I'll try to work a little more and
prepare it for 3.9?

I quite like your idea of .../dma-buf/<exporting_file.c>/...  , which would
need the above as well :)

>
> ~Maarten
>
> Best regards,
~Sumit.
Sumit Semwal Dec. 17, 2012, 8:56 a.m. | #8
On 14 December 2012 16:04, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> Missed one ...
>
> On Fri, Dec 14, 2012 at 10:36 AM,  <sumit.semwal@ti.com> wrote:
> > +               list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
> > +                       seq_printf(s, "\t\t");
> > +
> > +                       seq_printf(s, "%s\n", attach_obj->dev->init_name);
> > +                       attach_count++;
> > +               }
>
> You need to hold dmabuf->lock while walking the attachment list.
> -Daniel


Thanks Daniel!

Will update in next version.
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



Best regards,

Sumit Semwal
Sumit Semwal Dec. 17, 2012, 8:57 a.m. | #9
On 17 December 2012 14:25, Sumit Semwal <sumit.semwal@linaro.org> wrote:
Apologies for re-sending, since the gmail ui 'decided' to set some
formatting options by default!
> Hi Maarten,
>
> On 14 December 2012 17:27, Maarten Lankhorst <m.b.lankhorst@gmail.com>
> wrote:
>>
>> Op 14-12-12 10:36, sumit.semwal@ti.com schreef:
>> > From: Sumit Semwal <sumit.semwal@linaro.org>
>> >
>> > Add debugfs support to make it easier to print debug information
>> > about the dma-buf buffers.
>> >
>> I like the idea, I don't know if it could be done in a free manner, but
>> for bonus points
>> could we also have the dma-buf fd be obtainable that way from a debugfs
>> entry?
>>
>> Doing so would allow me to 'steal' a dma-buf from an existing mapping
>> easily, and test against that.
>>
>> Also I think the name of the device and process that exported the dma-buf
>> would be useful
>> to have as well, even if in case of the device that would mean changing
>> the api slightly to record it.
>>
>> I was thinking of having a directory structure like this:
>>
>> /sys/kernel/debug/dma_buf/stats
>>
>> and then for each dma-buf:
>>
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments
>> /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info
>>
>> Opening the fd file would give you back the original fd, or fail with -EIO
>> if refcount was dropped to 0.
>>
>> Would something like this be doable? I don't know debugfs that well, but I
>> don't see why it wouldn't be,
>
> Let me think more about it, but I am inclined to add simple support first,
> and then add more features to dma_buf debugfs as it grows.
>
> I still would want to take Daniel's suggestion on dma_buf_export_named()
> before I push this patch, so I guess I'll try to work a little more and
> prepare it for 3.9?
>
> I quite like your idea of .../dma-buf/<exporting_file.c>/...  , which would
> need the above as well :)
>>
>>
>> ~Maarten
>>
> Best regards,
> ~Sumit.
>



--
Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
Dave Airlie Dec. 20, 2012, 1:26 a.m. | #10
On Fri, Dec 14, 2012 at 7:36 PM,  <sumit.semwal@ti.com> wrote:
> From: Sumit Semwal <sumit.semwal@linaro.org>
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>

I like thie idea,

/home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: In function
‘dma_buf_describe’:
/home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:563:5:
warning: format ‘%d’ expects argument of type ‘int’, but argument 6
has type ‘long int’ [-Wformat]
/home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c: At top level:
/home/airlied/devel/kernel/drm-2.6/drivers/base/dma-buf.c:528:123:
warning: ‘dma_buf_init’ defined but not used [-Wunused-function]

not sure my compiler does though.

Dave.
Dave Airlie Dec. 20, 2012, 3:13 a.m. | #11
On Thu, Dec 20, 2012 at 11:26 AM, Dave Airlie <airlied@gmail.com> wrote:
> On Fri, Dec 14, 2012 at 7:36 PM,  <sumit.semwal@ti.com> wrote:
>> From: Sumit Semwal <sumit.semwal@linaro.org>
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>

I've attached two patches that make it work on my system, and fix the warnings,

I've used it to debug some leaks I was seeing, feel free to squash
these patches into the original patch.

Dave.

Patch

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..49fcf0f 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,9 +27,18 @@ 
 #include <linux/dma-buf.h>
 #include <linux/anon_inodes.h>
 #include <linux/export.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
 
 static inline int is_dma_buf_file(struct file *);
 
+struct dma_buf_list {
+	struct list_head head;
+	struct mutex lock;
+};
+
+static struct dma_buf_list db_list;
+
 static int dma_buf_release(struct inode *inode, struct file *file)
 {
 	struct dma_buf *dmabuf;
@@ -40,6 +49,11 @@  static int dma_buf_release(struct inode *inode, struct file *file)
 	dmabuf = file->private_data;
 
 	dmabuf->ops->release(dmabuf);
+
+	mutex_lock(&db_list.lock);
+	list_del(&dmabuf->list_node);
+	mutex_unlock(&db_list.lock);
+
 	kfree(dmabuf);
 	return 0;
 }
@@ -120,6 +134,10 @@  struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops,
 	mutex_init(&dmabuf->lock);
 	INIT_LIST_HEAD(&dmabuf->attachments);
 
+	mutex_lock(&db_list.lock);
+	list_add(&dmabuf->list_node, &db_list.head);
+	mutex_unlock(&db_list.lock);
+
 	return dmabuf;
 }
 EXPORT_SYMBOL_GPL(dma_buf_export);
@@ -505,3 +523,134 @@  void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
 		dmabuf->ops->vunmap(dmabuf, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+
+static int dma_buf_init_debugfs(void);
+static void dma_buf_uninit_debugfs(void);
+
+static void __init dma_buf_init(void)
+{
+	mutex_init(&db_list.lock);
+	INIT_LIST_HEAD(&db_list.head);
+	dma_buf_init_debugfs();
+}
+
+static void __exit dma_buf_deinit(void)
+{
+	dma_buf_uninit_debugfs();
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int dma_buf_describe(struct seq_file *s)
+{
+	int ret;
+	struct dma_buf *buf_obj;
+	struct dma_buf_attachment *attach_obj;
+	int count = 0, attach_count;
+	size_t size = 0;
+
+	ret = mutex_lock_interruptible(&db_list.lock);
+
+	if (ret)
+		return ret;
+
+	seq_printf(s, "\nDma-buf Objects:\n");
+	seq_printf(s, "\tsize\tflags\tmode\tcount\n");
+
+	list_for_each_entry(buf_obj, &db_list.head, list_node) {
+		seq_printf(s, "\t");
+
+		seq_printf(s, "%08zu\t%08x\t%08x\t%08d\n",
+				buf_obj->size, buf_obj->file->f_flags,
+				buf_obj->file->f_mode,
+				buf_obj->file->f_count.counter);
+
+		seq_printf(s, "\t\tAttached Devices:\n");
+		attach_count = 0;
+
+		list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
+			seq_printf(s, "\t\t");
+
+			seq_printf(s, "%s\n", attach_obj->dev->init_name);
+			attach_count++;
+		}
+
+		seq_printf(s, "\n\t\tTotal %d devices attached\n",
+				attach_count);
+
+		count++;
+		size += buf_obj->size;
+	}
+
+	seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
+
+	mutex_unlock(&db_list.lock);
+	return 0;
+}
+
+static int dma_buf_show(struct seq_file *s, void *unused)
+{
+	void (*func)(struct seq_file *) = s->private;
+	func(s);
+	return 0;
+}
+
+static int dma_buf_debug_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, dma_buf_show, inode->i_private);
+}
+
+static const struct file_operations dma_buf_debug_fops = {
+	.open           = dma_buf_debug_open,
+	.read           = seq_read,
+	.llseek         = seq_lseek,
+	.release        = single_release,
+};
+
+static struct dentry *dma_buf_debugfs_dir;
+
+static int dma_buf_init_debugfs(void)
+{
+	int err = 0;
+	dma_buf_debugfs_dir = debugfs_create_dir("dma_buf", NULL);
+	if (IS_ERR(dma_buf_debugfs_dir)) {
+		err = PTR_ERR(dma_buf_debugfs_dir);
+		dma_buf_debugfs_dir = NULL;
+		return err;
+	}
+
+	err = dma_buf_debugfs_create_file("bufinfo", dma_buf_describe);
+
+	if (err)
+		pr_debug("dma_buf: debugfs: failed to create node bufinfo\n");
+
+	return err;
+}
+
+static void dma_buf_uninit_debugfs(void)
+{
+	if (dma_buf_debugfs_dir)
+		debugfs_remove_recursive(dma_buf_debugfs_dir);
+}
+
+int dma_buf_debugfs_create_file(const char *name,
+				int (*write)(struct seq_file *))
+{
+	struct dentry *d;
+
+	d = debugfs_create_file(name, S_IRUGO, dma_buf_debugfs_dir,
+			write, &dma_buf_debug_fops);
+
+	if (IS_ERR(d))
+		return PTR_ERR(d);
+
+	return 0;
+}
+#else
+static inline int dma_buf_init_debugfs(void)
+{
+	return 0;
+}
+static inline void dma_buf_uninit_debugfs(void)
+{
+}
+#endif
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..160453f 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@  struct dma_buf_ops {
  * @file: file pointer used for sharing buffers across, and for refcounting.
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
+ * @list_node: node for dma_buf accounting and debugging.
  * @priv: exporter specific private data for this buffer object.
  */
 struct dma_buf {
@@ -121,6 +122,8 @@  struct dma_buf {
 	const struct dma_buf_ops *ops;
 	/* mutex to serialize list manipulation and attach/detach */
 	struct mutex lock;
+
+	struct list_head list_node;
 	void *priv;
 };
 
@@ -183,5 +186,6 @@  int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
 		 unsigned long);
 void *dma_buf_vmap(struct dma_buf *);
 void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-
+int dma_buf_debugfs_create_file(const char *name,
+				int (*write)(struct seq_file *));
 #endif /* __DMA_BUF_H__ */