| Message ID | 20240328145323.68872-1-tursulin@igalia.com |
|---|---|
| State | New |
| Headers | show |
| Series | dma-buf: Do not build debugfs related code when !CONFIG_DEBUG_FS | expand |
On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <tursulin@igalia.com> wrote: > > From: Tvrtko Ursulin <tursulin@ursulin.net> > > 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 <tursulin@ursulin.net> Reviewed-by: T.J. Mercier <tjmercier@google.com>
On 29/03/2024 00:00, T.J. Mercier wrote: > On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin <tursulin@igalia.com> wrote: >> >> From: Tvrtko Ursulin <tursulin@ursulin.net> >> >> 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 <tursulin@ursulin.net> > > Reviewed-by: T.J. Mercier <tjmercier@google.com> Thanks! How would patches to dma-buf be typically landed? Via what tree I mean? drm-misc-next? Regards, Tvrtko
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 <tursulin@igalia.com> >> wrote: >>> >>> From: Tvrtko Ursulin <tursulin@ursulin.net> >>> >>> 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 <tursulin@ursulin.net> >> >> Reviewed-by: T.J. Mercier <tjmercier@google.com> > > 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 <christian.koenig@amd.com> 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 <tursulin@igalia.com> >>> wrote: >>>> >>>> From: Tvrtko Ursulin <tursulin@ursulin.net> >>>> >>>> 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 <tursulin@ursulin.net> >>> >>> Reviewed-by: T.J. Mercier <tjmercier@google.com> >> >> 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 > <christian.koenig@amd.com> 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
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 <tursulin@igalia.com> >>>> wrote: >>>>> >>>>> From: Tvrtko Ursulin <tursulin@ursulin.net> >>>>> >>>>> 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 <tursulin@ursulin.net> >>>> >>>> Reviewed-by: T.J. Mercier <tjmercier@google.com> >>> >>> 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 >> <christian.koenig@amd.com> 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
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;