From: Tvrtko Ursulin <[email protected]>
There is no point in compiling in the list and mutex operations which are
only used from the dma-buf debugfs code, if debugfs is not compiled in.
Put the code in questions behind some kconfig guards and so save some text
and maybe even a pointer per object at runtime when not enabled.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Cc: Sumit Semwal <[email protected]>
Cc: "Christian König" <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
drivers/dma-buf/dma-buf.c | 56 ++++++++++++++++++++++++---------------
include/linux/dma-buf.h | 2 ++
2 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 8fe5aa67b167..8892bc701a66 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -35,12 +35,35 @@
static inline int is_dma_buf_file(struct file *);
-struct dma_buf_list {
- struct list_head head;
- struct mutex lock;
-};
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+static DEFINE_MUTEX(debugfs_list_mutex);
+static LIST_HEAD(debugfs_list);
-static struct dma_buf_list db_list;
+static void __dma_buf_debugfs_list_add(struct dma_buf *dmabuf)
+{
+ mutex_lock(&debugfs_list_mutex);
+ list_add(&dmabuf->list_node, &debugfs_list);
+ mutex_unlock(&debugfs_list_mutex);
+}
+
+static void __dma_buf_debugfs_list_del(struct dma_buf *dmabuf)
+{
+ if (!dmabuf)
+ return;
+
+ mutex_lock(&debugfs_list_mutex);
+ list_del(&dmabuf->list_node);
+ mutex_unlock(&debugfs_list_mutex);
+}
+#else
+static void __dma_buf_debugfs_list_add(struct dma_buf *dmabuf)
+{
+}
+
+static void __dma_buf_debugfs_list_del(struct file *file)
+{
+}
+#endif
static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
{
@@ -89,17 +112,10 @@ static void dma_buf_release(struct dentry *dentry)
static int dma_buf_file_release(struct inode *inode, struct file *file)
{
- struct dma_buf *dmabuf;
-
if (!is_dma_buf_file(file))
return -EINVAL;
- dmabuf = file->private_data;
- if (dmabuf) {
- mutex_lock(&db_list.lock);
- list_del(&dmabuf->list_node);
- mutex_unlock(&db_list.lock);
- }
+ __dma_buf_debugfs_list_del(file->private_data);
return 0;
}
@@ -672,9 +688,7 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
file->f_path.dentry->d_fsdata = dmabuf;
dmabuf->file = file;
- mutex_lock(&db_list.lock);
- list_add(&dmabuf->list_node, &db_list.head);
- mutex_unlock(&db_list.lock);
+ __dma_buf_debugfs_list_add(dmabuf);
return dmabuf;
@@ -1611,7 +1625,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
size_t size = 0;
int ret;
- ret = mutex_lock_interruptible(&db_list.lock);
+ ret = mutex_lock_interruptible(&debugfs_list_mutex);
if (ret)
return ret;
@@ -1620,7 +1634,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\t%-8s\tname\n",
"size", "flags", "mode", "count", "ino");
- list_for_each_entry(buf_obj, &db_list.head, list_node) {
+ list_for_each_entry(buf_obj, &debugfs_list, list_node) {
ret = dma_resv_lock_interruptible(buf_obj->resv, NULL);
if (ret)
@@ -1657,11 +1671,11 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
- mutex_unlock(&db_list.lock);
+ mutex_unlock(&debugfs_list_mutex);
return 0;
error_unlock:
- mutex_unlock(&db_list.lock);
+ mutex_unlock(&debugfs_list_mutex);
return ret;
}
@@ -1718,8 +1732,6 @@ static int __init dma_buf_init(void)
if (IS_ERR(dma_buf_mnt))
return PTR_ERR(dma_buf_mnt);
- mutex_init(&db_list.lock);
- INIT_LIST_HEAD(&db_list.head);
dma_buf_init_debugfs();
return 0;
}
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 8ff4add71f88..36216d28d8bd 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -370,8 +370,10 @@ struct dma_buf {
*/
struct module *owner;
+#if IS_ENABLED(CONFIG_DEBUG_FS)
/** @list_node: node for dma_buf accounting and debugging. */
struct list_head list_node;
+#endif
/** @priv: exporter specific private data for this buffer object. */
void *priv;
--
2.44.0
On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <[email protected]> wrote:
>
> From: Tvrtko Ursulin <[email protected]>
>
> There is no point in compiling in the list and mutex operations which are
> only used from the dma-buf debugfs code, if debugfs is not compiled in.
>
> Put the code in questions behind some kconfig guards and so save some text
> and maybe even a pointer per object at runtime when not enabled.
>
> Signed-off-by: Tvrtko Ursulin <[email protected]>
Reviewed-by: T.J. Mercier <[email protected]>
Am 01.04.24 um 14:39 schrieb Tvrtko Ursulin:
>
> On 29/03/2024 00:00, T.J. Mercier wrote:
>> On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <[email protected]>
>> wrote:
>>>
>>> From: Tvrtko Ursulin <[email protected]>
>>>
>>> There is no point in compiling in the list and mutex operations
>>> which are
>>> only used from the dma-buf debugfs code, if debugfs is not compiled in.
>>>
>>> Put the code in questions behind some kconfig guards and so save
>>> some text
>>> and maybe even a pointer per object at runtime when not enabled.
>>>
>>> Signed-off-by: Tvrtko Ursulin <[email protected]>
>>
>> Reviewed-by: T.J. Mercier <[email protected]>
>
> Thanks!
>
> How would patches to dma-buf be typically landed? Via what tree I
> mean? drm-misc-next?
That should go through drm-misc-next.
And feel free to add Reviewed-by: Christian König
<[email protected]> as well.
Regards,
Christian.
>
> Regards,
>
> Tvrtko
On 01/04/2024 13:45, Christian König wrote:
> Am 01.04.24 um 14:39 schrieb Tvrtko Ursulin:
>>
>> On 29/03/2024 00:00, T.J. Mercier wrote:
>>> On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <[email protected]>
>>> wrote:
>>>>
>>>> From: Tvrtko Ursulin <[email protected]>
>>>>
>>>> There is no point in compiling in the list and mutex operations
>>>> which are
>>>> only used from the dma-buf debugfs code, if debugfs is not compiled in.
>>>>
>>>> Put the code in questions behind some kconfig guards and so save
>>>> some text
>>>> and maybe even a pointer per object at runtime when not enabled.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <[email protected]>
>>>
>>> Reviewed-by: T.J. Mercier <[email protected]>
>>
>> Thanks!
>>
>> How would patches to dma-buf be typically landed? Via what tree I
>> mean? drm-misc-next?
>
> That should go through drm-misc-next.
>
> And feel free to add Reviewed-by: Christian König
> <[email protected]> as well.
Thanks!
Maarten if I got it right you are handling the next drm-misc-next pull -
could you merge this one please?
Regards,
Tvrtko
On 29/03/2024 00:00, T.J. Mercier wrote:
> On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <[email protected]> wrote:
>>
>> From: Tvrtko Ursulin <[email protected]>
>>
>> There is no point in compiling in the list and mutex operations which are
>> only used from the dma-buf debugfs code, if debugfs is not compiled in.
>>
>> Put the code in questions behind some kconfig guards and so save some text
>> and maybe even a pointer per object at runtime when not enabled.
>>
>> Signed-off-by: Tvrtko Ursulin <[email protected]>
>
> Reviewed-by: T.J. Mercier <[email protected]>
Thanks!
How would patches to dma-buf be typically landed? Via what tree I mean?
drm-misc-next?
Regards,
Tvrtko
Hi Tvrtko,
On 4/1/24 10:21, Tvrtko Ursulin wrote:
>
> On 01/04/2024 13:45, Christian König wrote:
>> Am 01.04.24 um 14:39 schrieb Tvrtko Ursulin:
>>>
>>> On 29/03/2024 00:00, T.J. Mercier wrote:
>>>> On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <[email protected]>
>>>> wrote:
>>>>>
>>>>> From: Tvrtko Ursulin <[email protected]>
>>>>>
>>>>> There is no point in compiling in the list and mutex operations
>>>>> which are
>>>>> only used from the dma-buf debugfs code, if debugfs is not compiled
>>>>> in.
>>>>>
>>>>> Put the code in questions behind some kconfig guards and so save
>>>>> some text
>>>>> and maybe even a pointer per object at runtime when not enabled.
>>>>>
>>>>> Signed-off-by: Tvrtko Ursulin <[email protected]>
>>>>
>>>> Reviewed-by: T.J. Mercier <[email protected]>
>>>
>>> Thanks!
>>>
>>> How would patches to dma-buf be typically landed? Via what tree I
>>> mean? drm-misc-next?
>>
>> That should go through drm-misc-next.
>>
>> And feel free to add Reviewed-by: Christian König
>> <[email protected]> as well.
>
> Thanks!
>
> Maarten if I got it right you are handling the next drm-misc-next pull -
> could you merge this one please?
Applied to drm-misc/drm-misc-next!
Best Regards,
- Maíra
>
> Regards,
>
> Tvrtko