Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
On 17 December 2012 14:25, Sumit Semwal sumit.sem...@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.lankho...@gmail.com wrote: Op 14-12-12 10:36, sumit.sem...@ti.com schreef: From: Sumit Semwal sumit.sem...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
Hi,
On 12/14/2012 10:36 AM, sumit.sem...@ti.com wrote:
From: Sumit Semwal sumit.sem...@linaro.org
Add debugfs support to make it easier to print debug information
about the dma-buf buffers.
Signed-off-by: Sumit Semwal sumit.sem...@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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
Op 14-12-12 10:36, sumit.sem...@ti.com schreef: From: Sumit Semwal sumit.sem...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Op 14-12-12 10:36, sumit.sem...@ti.com schreef: From: Sumit Semwal sumit.sem...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
Op 14-12-12 15:11, Rob Clark schreef: On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: Op 14-12-12 10:36, sumit.sem...@ti.com schreef: From: Sumit Semwal sumit.sem...@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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
