Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6 participants
3320 discussions

by Jesse Barker

Hi all, With all of the attention that the Common Display Framework is getting, I was wondering if it was worth having a BoF discussion at ELC next month in San Francisco. This will be only a couple of weeks after FOSDEM, but given the pace that things seem to be moving, that could be a great opportunity either to have a follow-on discussion, or simply to involve a slightly different cross-section of the community in a face-to-face discussion. If folks could let me know that they'll be at ELC and are interested in a BoF there, I'll look into getting it set up. cheers, Jesse

13 years

[PATCH] gpu: ion: Add ion_share_dma_buf_kernel

by Johan Mossberg

ion_share_dma_buf_kernel enables you to share ion buffers via dma buf for kernel only use cases. Useful for example when a GPU driver using ion wants to share its output buffers with a 3d party display controller driver supporting dma buf. Signed-off-by: Johan Mossberg <johan.mossberg(a)stericsson.com> --- drivers/gpu/ion/ion.c | 18 ++++++++++++++++-- include/linux/ion.h | 8 ++++++++ 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c index 748ff7d..31bb5e1 100644 --- a/drivers/gpu/ion/ion.c +++ b/drivers/gpu/ion/ion.c @@ -991,12 +991,12 @@ struct dma_buf_ops dma_buf_ops = { .kunmap = ion_dma_buf_kunmap, }; -int ion_share_dma_buf(struct ion_client *client, struct ion_handle *handle) +struct dma_buf *ion_share_dma_buf_kernel(struct ion_client *client, + struct ion_handle *handle) { struct ion_buffer *buffer; struct dma_buf *dmabuf; bool valid_handle; - int fd; mutex_lock(&client->lock); valid_handle = ion_handle_validate(client, handle); @@ -1013,6 +1013,20 @@ int ion_share_dma_buf(struct ion_client *client, struct ion_handle *handle) ion_buffer_put(buffer); return PTR_ERR(dmabuf); } + + return dmabuf; +} +EXPORT_SYMBOL(ion_share_dma_buf_kernel); + +int ion_share_dma_buf(struct ion_client *client, struct ion_handle *handle) +{ + struct dma_buf *dmabuf; + int fd; + + dmabuf = ion_share_dma_buf_kernel(client, handle); + if (IS_ERR(dmabuf)) + return PTR_ERR(dmabuf); + fd = dma_buf_fd(dmabuf, O_CLOEXEC); if (fd < 0) dma_buf_put(dmabuf); diff --git a/include/linux/ion.h b/include/linux/ion.h index 3ccc75a..cfb831d 100644 --- a/include/linux/ion.h +++ b/include/linux/ion.h @@ -210,6 +210,14 @@ void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle); void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle); /** + * ion_share_dma_buf_kernel() - share buffer as dma-buf + * @client: the client + * @handle: the handle + */ +struct dma_buf *ion_share_dma_buf_kernel(struct ion_client *client, + struct ion_handle *buf); + +/** * ion_share_dma_buf() - given an ion client, create a dma-buf fd * @client: the client * @handle: the handle -- 1.8.0

13 years

Re: [Linaro-mm-sig] [PATCHv2] gpu: ion: Add ion_share_dma_buf_kernel

by Johan Mossberg

Hi Rebecca, Is this patch accepted for ion mainline or do you have more comments/questions? /Johan Mossberg On 12/13/2012 10:24 AM, Johan Mossberg wrote: > ion_share_dma_buf_kernel enables you to share ion buffers via dma buf > for kernel only use cases. Useful for example when a GPU driver using > ion wants to share its output buffers with a 3d party display > controller driver supporting dma buf. > > Signed-off-by: Johan Mossberg <johan.mossberg(a)stericsson.com> > --- > drivers/gpu/ion/ion.c | 22 ++++++++++++++++++---- > include/linux/ion.h | 8 ++++++++ > 2 files changed, 26 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c > index 3872095..e7b0d0b 100644 > --- a/drivers/gpu/ion/ion.c > +++ b/drivers/gpu/ion/ion.c > @@ -955,19 +955,19 @@ struct dma_buf_ops dma_buf_ops = { > .kunmap = ion_dma_buf_kunmap, > }; > > -int ion_share_dma_buf(struct ion_client *client, struct ion_handle *handle) > +struct dma_buf *ion_share_dma_buf_kernel(struct ion_client *client, > + struct ion_handle *handle) > { > struct ion_buffer *buffer; > struct dma_buf *dmabuf; > bool valid_handle; > - int fd; > > mutex_lock(&client->lock); > valid_handle = ion_handle_validate(client, handle); > mutex_unlock(&client->lock); > if (!valid_handle) { > WARN(1, "%s: invalid handle passed to share.\n", __func__); > - return -EINVAL; > + return ERR_PTR(-EINVAL); > } > > buffer = handle->buffer; > @@ -975,8 +975,22 @@ int ion_share_dma_buf(struct ion_client *client, struct ion_handle *handle) > dmabuf = dma_buf_export(buffer, &dma_buf_ops, buffer->size, O_RDWR); > if (IS_ERR(dmabuf)) { > ion_buffer_put(buffer); > - return PTR_ERR(dmabuf); > + return dmabuf; > } > + > + return dmabuf; > +} > +EXPORT_SYMBOL(ion_share_dma_buf_kernel); > + > +int ion_share_dma_buf(struct ion_client *client, struct ion_handle *handle) > +{ > + struct dma_buf *dmabuf; > + int fd; > + > + dmabuf = ion_share_dma_buf_kernel(client, handle); > + if (IS_ERR(dmabuf)) > + return PTR_ERR(dmabuf); > + > fd = dma_buf_fd(dmabuf, O_CLOEXEC); > if (fd < 0) > dma_buf_put(dmabuf); > diff --git a/include/linux/ion.h b/include/linux/ion.h > index a7d399c..8720e9b 100644 > --- a/include/linux/ion.h > +++ b/include/linux/ion.h > @@ -205,6 +205,14 @@ void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle); > void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle); > > /** > + * ion_share_dma_buf_kernel() - share buffer as dma-buf > + * @client: the client > + * @handle: the handle > + */ > +struct dma_buf *ion_share_dma_buf_kernel(struct ion_client *client, > + struct ion_handle *buf); > + > +/** > * ion_share_dma_buf() - given an ion client, create a dma-buf fd > * @client: the client > * @handle: the handle > -- > 1.8.0 > > > _______________________________________________ > Linaro-mm-sig mailing list > Linaro-mm-sig(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig > >

13 years

[PATCH v2] arm: dma mapping: export arm iommu functions

by Prathyush K

This patch adds EXPORT_SYMBOL_GPL calls to the three arm iommu functions - arm_iommu_create_mapping, arm_iommu_free_mapping and arm_iommu_attach_device. These three functions are arm specific wrapper functions for creating/freeing/using an iommu mapping and they are called by various drivers. If any of these drivers need to be built as dynamic modules, these functions need to be exported. Changelog v2: using EXPORT_SYMBOL_GPL as suggested by Marek. Signed-off-by: Prathyush K <prathyush.k(a)samsung.com> --- arch/arm/mm/dma-mapping.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6b2fb87..226ebcf 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1797,6 +1797,7 @@ err2: err: return ERR_PTR(err); } +EXPORT_SYMBOL_GPL(arm_iommu_create_mapping); static void release_iommu_mapping(struct kref *kref) { @@ -1813,6 +1814,7 @@ void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping) if (mapping) kref_put(&mapping->kref, release_iommu_mapping); } +EXPORT_SYMBOL_GPL(arm_iommu_release_mapping); /** * arm_iommu_attach_device @@ -1841,5 +1843,6 @@ int arm_iommu_attach_device(struct device *dev, pr_debug("Attached IOMMU controller to %s device.\n", dev_name(dev)); return 0; } +EXPORT_SYMBOL_GPL(arm_iommu_attach_device); #endif -- 1.8.0

13 years, 1 month

[RFC] ARM: DMA-Mapping: add a new attribute to clear buffer

by daeinki＠gmail.com

From: Inki Dae <inki.dae(a)samsung.com> This patch adds a new attribute, DMA_ATTR_SKIP_BUFFER_CLEAR to skip buffer clearing. The buffer clearing also flushes CPU cache so this operation has performance deterioration a little bit. With this patch, allocated buffer region is cleared as default. So if you want to skip the buffer clearing, just set this attribute. But this flag should be used carefully because this use might get access to some vulnerable content such as security data. So with this patch, we make sure that all pages will be somehow cleared before exposing to userspace. For example, let's say that the security data had been stored in some memory and freed without clearing it. And then malicious process allocated the region though some buffer allocator such as gem and ion without clearing it, and requested blit operation with cleared another buffer though gpu or other drivers. At this time, the malicious process could access the security data. Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- arch/arm/mm/dma-mapping.c | 6 ++++-- include/linux/dma-attrs.h | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6b2fb87..fbe9dff 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1058,7 +1058,8 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, if (!page) goto error; - __dma_clear_buffer(page, size); + if (!dma_get_attr(DMA_ATTR_SKIP_BUFFER_CLEAR, attrs)) + __dma_clear_buffer(page, size); for (i = 0; i < count; i++) pages[i] = page + i; @@ -1082,7 +1083,8 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, pages[i + j] = pages[i] + j; } - __dma_clear_buffer(pages[i], PAGE_SIZE << order); + if (!dma_get_attr(DMA_ATTR_SKIP_BUFFER_CLEAR, attrs)) + __dma_clear_buffer(pages[i], PAGE_SIZE << order); i += 1 << order; count -= 1 << order; } diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h index c8e1831..2592c05 100644 --- a/include/linux/dma-attrs.h +++ b/include/linux/dma-attrs.h @@ -18,6 +18,7 @@ enum dma_attr { DMA_ATTR_NO_KERNEL_MAPPING, DMA_ATTR_SKIP_CPU_SYNC, DMA_ATTR_FORCE_CONTIGUOUS, + DMA_ATTR_SKIP_BUFFER_CLEAR, DMA_ATTR_MAX, }; -- 1.7.4.1

13 years, 1 month

[PATCH] arm: dma mapping: export arm iommu functions

by Prathyush K

This patch adds EXPORT_SYMBOL calls to the three arm iommu functions - arm_iommu_create_mapping, arm_iommu_free_mapping and arm_iommu_attach_device. These functions can now be called from dynamic modules. Signed-off-by: Prathyush K <prathyush.k(a)samsung.com> --- arch/arm/mm/dma-mapping.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6b2fb87..c0f0f43 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1797,6 +1797,7 @@ err2: err: return ERR_PTR(err); } +EXPORT_SYMBOL(arm_iommu_create_mapping); static void release_iommu_mapping(struct kref *kref) { @@ -1813,6 +1814,7 @@ void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping) if (mapping) kref_put(&mapping->kref, release_iommu_mapping); } +EXPORT_SYMBOL(arm_iommu_release_mapping); /** * arm_iommu_attach_device @@ -1841,5 +1843,6 @@ int arm_iommu_attach_device(struct device *dev, pr_debug("Attached IOMMU controller to %s device.\n", dev_name(dev)); return 0; } +EXPORT_SYMBOL(arm_iommu_attach_device); #endif -- 1.8.0

13 years, 1 month

[PATCH] [RFC] dma-buf: implement vmap refcounting in the interface logic

by Daniel Vetter

All drivers which implement this need to have some sort of refcount to allow concurrent vmap usage. Hence implement this in the dma-buf core. To protect against concurrent calls we need a lock, which potentially causes new funny locking inversions. But this shouldn't be a problem for exporters with statically allocated backing storage, and more dynamic drivers have decent issues already anyway. Inspired by some refactoring patches from Aaron Plattner, who implemented the same idea, but only for drm/prime drivers. v2: Check in dma_buf_release that no dangling vmaps are left. Suggested by Aaron Plattner. We might want to do similar checks for attachments, but that's for another patch. Also fix up ERR_PTR return for vmap. Cc: Aaron Plattner <aplattner(a)nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- Compile-tested only - Aaron has been bugging me too a bit too often about this on irc. Cheers, Daniel --- Documentation/dma-buf-sharing.txt | 6 +++++- drivers/base/dma-buf.c | 42 ++++++++++++++++++++++++++++++++++----- include/linux/dma-buf.h | 4 +++- 3 files changed, 45 insertions(+), 7 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0188903..4966b1b 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three steps: void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) The vmap call can fail if there is no vmap support in the exporter, or if it - runs out of vmalloc space. Fallback to kmap should be implemented. + runs out of vmalloc space. Fallback to kmap should be implemented. Note that + the dma-buf layer keeps a reference count for all vmap access and calls down + into the exporter's vmap function only when no vmapping exists, and only + unmaps it once. Protection against concurrent vmap/vunmap calls is provided + by taking the dma_buf->lock mutex. 3. Finish access diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index a3f79c4..36af5de 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file *file) dmabuf = file->private_data; + BUG_ON(dmabuf->vmapping_counter); + dmabuf->ops->release(dmabuf); kfree(dmabuf); return 0; @@ -482,12 +484,34 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap); */ void *dma_buf_vmap(struct dma_buf *dmabuf) { + void *ptr; + if (WARN_ON(!dmabuf)) return NULL; - if (dmabuf->ops->vmap) - return dmabuf->ops->vmap(dmabuf); - return NULL; + if (!dmabuf->ops->vmap) + return NULL; + + mutex_lock(&dmabuf->lock); + if (dmabuf->vmapping_counter) { + dmabuf->vmapping_counter++; + BUG_ON(!dmabuf->vmap_ptr); + ptr = dmabuf->vmap_ptr; + goto out_unlock; + } + + BUG_ON(dmabuf->vmap_ptr); + + ptr = dmabuf->ops->vmap(dmabuf); + if (IS_ERR_OR_NULL(ptr)) + goto out_unlock; + + dmabuf->vmap_ptr = ptr; + dmabuf->vmapping_counter = 1; + +out_unlock: + mutex_unlock(&dmabuf->lock); + return ptr; } EXPORT_SYMBOL_GPL(dma_buf_vmap); @@ -501,7 +525,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) if (WARN_ON(!dmabuf)) return; - if (dmabuf->ops->vunmap) - dmabuf->ops->vunmap(dmabuf, vaddr); + BUG_ON(!dmabuf->vmap_ptr); + BUG_ON(dmabuf->vmapping_counter > 0); + + mutex_lock(&dmabuf->lock); + if (--dmabuf->vmapping_counter == 0) { + if (dmabuf->ops->vunmap) + dmabuf->ops->vunmap(dmabuf, vaddr); + dmabuf->vmap_ptr = NULL; + } + mutex_unlock(&dmabuf->lock); } EXPORT_SYMBOL_GPL(dma_buf_vunmap); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index bd2e52c..e3bf2f6 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -119,8 +119,10 @@ struct dma_buf { struct file *file; struct list_head attachments; const struct dma_buf_ops *ops; - /* mutex to serialize list manipulation and attach/detach */ + /* mutex to serialize list manipulation, attach/detach and vmap/unmap */ struct mutex lock; + unsigned vmapping_counter; + void *vmap_ptr; void *priv; }; -- 1.7.11.7

13 years, 1 month

[GIT PULL]: dma-buf updates for 3.8

by Sumit Semwal

Hi Linus, A fairly small dma-buf pull request for 3.8 - only 2 patches. Could you please pull? Thanks! ~Sumit. The following changes since commit f01af9f85855e38fbd601e033a8eac204cc4cc1c: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2012-12-19 20:31:02 -0800) are available in the git repository at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git tags/tag-for-linus-3.8 for you to fetch changes up to ada65c74059f8c104f1b467c126205471634c435: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER (2012-12-20 12:05:06 +0530) ---------------------------------------------------------------- 3.8: dma-buf minor updates ---------------------------------------------------------------- Maarten Lankhorst (1): dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER Rob Clark (1): dma-buf: might_sleep() in dma_buf_unmap_attachment() drivers/base/dma-buf.c | 2 + include/linux/dma-buf.h | 99 ----------------------------------------------- 2 files changed, 2 insertions(+), 99 deletions(-)

13 years, 1 month

[PATCH] dma-buf: Add debugfs support

by sumit.semwal＠ti.com

From: Sumit Semwal <sumit.semwal(a)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(a)ti.com> --- 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

13 years, 1 month

drm prime/dma-buf import lifetime issue

by Dave Airlie

So I've gotten back to playing with prime for a day, and found some old intel/radeon tests I had failing, Tracked it down to a lifetime issue with the current code and can think of two fixes, The problem scenario is 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref object 6. i915: unref object So we end up at this point, with a imported buffer record for the dma_buf on the i915 file private. Now if a subsequent test (without closing the drm fd) reallocates the dma_buf with the same address, we can end up seeing that. So why doesn't that reference get cleaned up? So the reference gets added above at step 2, and when radeon unrefs the object, i915 gets the dma-buf release callback, however at that stage we don't actually have the file priv to remove the pointer from, so it dangles there. Possible fixes: a) take a reference on the dma_buf attached to the gem handle when we export it, keep it until the gem handle goes away. I'm unsure if this could create zombie objects, since the dma buf has a reference on the gem object, but since the gem handle is separate to the object it might work. b) don't keep track of dma_buf, keep track of gem objects, when we get a lookup, check inside the gem object, since currently we NULL out the export_dma_buf when we hit the release path, apart from the fact I'm sure the locking is foobar, c) scan all the file privs for all the devices, no. Anyone else any better plans? Dave.

13 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig