- Linaro-mm-sig - lists.linaro.org

[PATCH -next] dma-buf: fix documentation build warnings

by Randy Dunlap

From: Randy Dunlap <rdunlap(a)infradead.org> Fix documentation warnings in dma-buf.[hc]: ../drivers/dma-buf/dma-buf.c:678: warning: Function parameter or member 'importer_ops' not described in 'dma_buf_dynamic_attach' ../drivers/dma-buf/dma-buf.c:678: warning: Function parameter or member 'importer_priv' not described in 'dma_buf_dynamic_attach' ../include/linux/dma-buf.h:339: warning: Incorrect use of kernel-doc format: * @move_notify Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-buf.c | 4 ++-- include/linux/dma-buf.h | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) --- linux-next-20200407.orig/drivers/dma-buf/dma-buf.c +++ linux-next-20200407/drivers/dma-buf/dma-buf.c @@ -655,8 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); * calls attach() of dma_buf_ops to allow device-specific attach functionality * @dmabuf: [in] buffer to attach device to. * @dev: [in] device to be attached. - * @importer_ops [in] importer operations for the attachment - * @importer_priv [in] importer private pointer for the attachment + * @importer_ops: [in] importer operations for the attachment + * @importer_priv: [in] importer private pointer for the attachment * * Returns struct dma_buf_attachment pointer for this attachment. Attachments * must be cleaned up by calling dma_buf_detach(). --- linux-next-20200407.orig/include/linux/dma-buf.h +++ linux-next-20200407/include/linux/dma-buf.h @@ -329,13 +329,12 @@ struct dma_buf { /** * struct dma_buf_attach_ops - importer operations for an attachment - * @move_notify: [optional] notification that the DMA-buf is moving * * Attachment operations implemented by the importer. */ struct dma_buf_attach_ops { /** - * @move_notify + * @move_notify: [optional] notification that the DMA-buf is moving * * If this callback is provided the framework can avoid pinning the * backing store while mappings exists.

5 years, 2 months

2
1
0 0

Re: [Linaro-mm-sig] [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

by Christoph Hellwig

On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote: > > > > config ZSMALLOC_PGTABLE_MAPPING > > > > bool "Use page table mapping to access object in zsmalloc" > > > > - depends on ZSMALLOC > > > > + depends on ZSMALLOC=y > > > > > > It's a bool so this shouldn't matter... not needed. > > > > My mm/Kconfig has: > > > > config ZSMALLOC > > tristate "Memory allocator for compressed pages" > > depends on MMU > > > > which I think means it can be modular, no? > > Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch > is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become > 'n' instead of 'y'. In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m, and that fits my understanding of the kbuild language. With this patch I can't anymore.

5 years, 2 months

2
1
0 0

Re: [Linaro-mm-sig] [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

by Randy Dunlap

On 4/8/20 8:15 AM, Matthew Wilcox wrote: > On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote: >> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote: >>> Hi, >>> >>> On 4/8/20 4:59 AM, Christoph Hellwig wrote: >>>> diff --git a/mm/Kconfig b/mm/Kconfig >>>> index 36949a9425b8..614cc786b519 100644 >>>> --- a/mm/Kconfig >>>> +++ b/mm/Kconfig >>>> @@ -702,7 +702,7 @@ config ZSMALLOC >>>> >>>> config ZSMALLOC_PGTABLE_MAPPING >>>> bool "Use page table mapping to access object in zsmalloc" >>>> - depends on ZSMALLOC >>>> + depends on ZSMALLOC=y >>> >>> It's a bool so this shouldn't matter... not needed. >> >> My mm/Kconfig has: >> >> config ZSMALLOC >> tristate "Memory allocator for compressed pages" >> depends on MMU >> >> which I think means it can be modular, no? ack. I misread it. > Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch > is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become > 'n' instead of 'y'. sigh, I wish that I had meant that. :) thanks. -- ~Randy

5 years, 2 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 18/28] mm: enforce that vmap can't map pages executable

by Christoph Hellwig

On Wed, Apr 08, 2020 at 01:38:36PM +0100, Mark Rutland wrote: > > +static inline pgprot_t pgprot_nx(pgprot_t prot) > > +{ > > + return __pgprot(pgprot_val(prot) | _PAGE_NX); > > +} > > +#define pgprot_nx pgprot_nx > > + > > #ifdef CONFIG_X86_PAE > > I reckon for arm64 we can do similar in our <asm/pgtable.h>: > > #define pgprot_nx(pgprot_t prot) \ > __pgprot_modify(prot, 0, PTE_PXN) > > ... matching the style of our existing pgprot_*() modifier helpers. I've added that for the next version with attribution to you.

5 years, 2 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] dma-buf: support 32bit DMA_BUF_SET_NAME ioctl

by Sumit Semwal

Hello, Daniel, your comments here, please? On Mon, 24 Feb 2020 at 09:09, Martin Liu <liumartin(a)google.com> wrote: > > On Tue, Jan 14, 2020 at 09:41:01PM +0800, Martin Liu wrote: > > CC more MLs for winder review. > > > This commit adds SET_NAME ioctl coversion to > > support 32 bit ioctl. > > > > Signed-off-by: Martin Liu <liumartin(a)google.com> > > --- > > drivers/dma-buf/dma-buf.c | 22 +++++++++++++++++++++- > > 1 file changed, 21 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index ce41cd9b758a..a73048b34843 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -25,6 +25,7 @@ > > #include <linux/mm.h> > > #include <linux/mount.h> > > #include <linux/pseudo_fs.h> > > +#include <linux/compat.h> > > > > #include <uapi/linux/dma-buf.h> > > #include <uapi/linux/magic.h> > > @@ -409,13 +410,32 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) > > dma_resv_unlock(dmabuf->resv); > > } > > > > +#ifdef CONFIG_COMPAT > > +static long dma_buf_ioctl_compat(struct file *file, unsigned int cmd, > > + unsigned long arg) > > +{ > > + switch (_IOC_NR(cmd)) { > > + case _IOC_NR(DMA_BUF_SET_NAME): > > + /* Fix up pointer size*/ > > + if (_IOC_SIZE(cmd) == sizeof(compat_uptr_t)) { > > + cmd &= ~IOCSIZE_MASK; > > + cmd |= sizeof(void *) << IOCSIZE_SHIFT; > > + } > > + break; > > + } > > + return dma_buf_ioctl(file, cmd, (unsigned long)compat_ptr(arg)); > > +} > > +#endif > > + > > static const struct file_operations dma_buf_fops = { > > .release = dma_buf_release, > > .mmap = dma_buf_mmap_internal, > > .llseek = dma_buf_llseek, > > .poll = dma_buf_poll, > > .unlocked_ioctl = dma_buf_ioctl, > > - .compat_ioctl = compat_ptr_ioctl, > > +#ifdef CONFIG_COMPAT > > + .compat_ioctl = dma_buf_ioctl_compat, > > +#endif > > .show_fdinfo = dma_buf_show_fdinfo, > > }; > > > > -- > > 2.25.0.rc1.283.g88dfdc4193-goog > > -- Thanks and regards, Sumit Semwal Linaro Consumer Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs

5 years, 2 months

2
1
0 0

[PATCH v2] staging: android: ion: Align with parenthesis

by John B. Wyatt IV

Align two different lines of arguments with the parenthesis of their respected function definitions. Fix style warnings of matching alignment. Reported by checkpatch. Signed-off-by: John B. Wyatt IV <jbwyatt4(a)gmail.com> --- v2: Change comment title and summary Suggested-by: Julia Lawall <julia.lawall(a)inria.fr> drivers/staging/android/ion/ion_page_pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c index f85ec5b16b65..0198b886d906 100644 --- a/drivers/staging/android/ion/ion_page_pool.c +++ b/drivers/staging/android/ion/ion_page_pool.c @@ -37,7 +37,7 @@ static void ion_page_pool_add(struct ion_page_pool *pool, struct page *page) } mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE, - 1 << pool->order); + 1 << pool->order); mutex_unlock(&pool->mutex); } @@ -57,7 +57,7 @@ static struct page *ion_page_pool_remove(struct ion_page_pool *pool, bool high) list_del(&page->lru); mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE, - -(1 << pool->order)); + -(1 << pool->order)); return page; } -- 2.25.1

5 years, 2 months

1
0
0 0

[PATCH] staging: android: ion: Fix parenthesis alignment

by John B. Wyatt IV

Fix 2 parenthesis alignment issues. Reported by checkpatch. Signed-off-by: John B. Wyatt IV <jbwyatt4(a)gmail.com> --- drivers/staging/android/ion/ion_page_pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c index f85ec5b16b65..0198b886d906 100644 --- a/drivers/staging/android/ion/ion_page_pool.c +++ b/drivers/staging/android/ion/ion_page_pool.c @@ -37,7 +37,7 @@ static void ion_page_pool_add(struct ion_page_pool *pool, struct page *page) } mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE, - 1 << pool->order); + 1 << pool->order); mutex_unlock(&pool->mutex); } @@ -57,7 +57,7 @@ static struct page *ion_page_pool_remove(struct ion_page_pool *pool, bool high) list_del(&page->lru); mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE, - -(1 << pool->order)); + -(1 << pool->order)); return page; } -- 2.25.1

5 years, 2 months

3
2
0 0

[PATCH] staging: android: ion: Fix parenthesis alignment

by John B. Wyatt IV

Fix 2 parenthesis alignment issues. Reported by checkpatch. Signed-off-by: John B. Wyatt IV <jbwyatt4(a)gmail.com> --- drivers/staging/android/ion/ion_page_pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c index f85ec5b16b65..0198b886d906 100644 --- a/drivers/staging/android/ion/ion_page_pool.c +++ b/drivers/staging/android/ion/ion_page_pool.c @@ -37,7 +37,7 @@ static void ion_page_pool_add(struct ion_page_pool *pool, struct page *page) } mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE, - 1 << pool->order); + 1 << pool->order); mutex_unlock(&pool->mutex); } @@ -57,7 +57,7 @@ static struct page *ion_page_pool_remove(struct ion_page_pool *pool, bool high) list_del(&page->lru); mod_node_page_state(page_pgdat(page), NR_KERNEL_MISC_RECLAIMABLE, - -(1 << pool->order)); + -(1 << pool->order)); return page; } -- 2.25.1

5 years, 2 months

1
0
0 0

[PATCH 1/7] dma-buf: add dynamic DMA-buf handling v15

by Christian König

On the exporter side we add optional explicit pinning callbacks. Which are called when the importer doesn't implement dynamic handling, move notification or need the DMA-buf locked in place for its use case. On the importer side we add an optional move_notify callback. This callback is used by the exporter to inform the importers that their mappings should be destroyed as soon as possible. This allows the exporter to provide the mappings without the need to pin the backing store. v2: don't try to invalidate mappings when the callback is NULL, lock the reservation obj while using the attachments, add helper to set the callback v3: move flag for invalidation support into the DMA-buf, use new attach_info structure to set the callback v4: use importer_priv field instead of mangling exporter priv. v5: drop invalidation_supported flag v6: squash together with pin/unpin changes v7: pin/unpin takes an attachment now v8: nuke dma_buf_attachment_(map|unmap)_locked, everything is now handled backward compatible v9: always cache when export/importer don't agree on dynamic handling v10: minimal style cleanup v11: drop automatically re-entry avoidance v12: rename callback to move_notify v13: add might_lock in appropriate places v14: rebase on separated locking change v15: add EXPERIMENTAL flag, some more code comments Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/Kconfig | 10 ++ drivers/dma-buf/dma-buf.c | 110 ++++++++++++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +- include/linux/dma-buf.h | 82 +++++++++++++-- 4 files changed, 188 insertions(+), 20 deletions(-) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index e7d820ce0724..ef73b678419c 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -39,6 +39,16 @@ config UDMABUF A driver to let userspace turn memfd regions into dma-bufs. Qemu can use this to create host dmabufs for guest framebuffers. +config DMABUF_MOVE_NOTIFY + bool "Move notify between drivers (EXPERIMENTAL)" + default n + help + Don''t pin buffers if the dynamic DMA-buf interface is available on both the + exporter as well as the importer. This fixes a security problem where + userspace is able to pin unrestricted amounts of memory through DMA-buf. + But marked experimental because we don''t jet have a consistent execution + context and memory management between drivers. + config DMABUF_SELFTESTS tristate "Selftests for the dma-buf interfaces" default n diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..5f10d1929476 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -527,6 +527,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) exp_info->ops->dynamic_mapping)) return ERR_PTR(-EINVAL); + if (WARN_ON(!exp_info->ops->dynamic_mapping && + (exp_info->ops->pin || exp_info->ops->unpin))) + return ERR_PTR(-EINVAL); + if (!try_module_get(exp_info->owner)) return ERR_PTR(-ENOENT); @@ -651,7 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); * calls attach() of dma_buf_ops to allow device-specific attach functionality * @dmabuf: [in] buffer to attach device to. * @dev: [in] device to be attached. - * @dynamic_mapping: [in] calling convention for map/unmap + * @importer_ops [in] importer operations for the attachment + * @importer_priv [in] importer private pointer for the attachment * * Returns struct dma_buf_attachment pointer for this attachment. Attachments * must be cleaned up by calling dma_buf_detach(). @@ -667,11 +672,13 @@ EXPORT_SYMBOL_GPL(dma_buf_put); */ struct dma_buf_attachment * dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, - bool dynamic_mapping) + const struct dma_buf_attach_ops *importer_ops, + void *importer_priv) { struct dma_buf_attachment *attach; int ret; + /* TODO: make move_notify mandatory if importer_ops are provided. */ if (WARN_ON(!dmabuf || !dev)) return ERR_PTR(-EINVAL); @@ -681,7 +688,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, attach->dev = dev; attach->dmabuf = dmabuf; - attach->dynamic_mapping = dynamic_mapping; + attach->importer_ops = importer_ops; + attach->importer_priv = importer_priv; if (dmabuf->ops->attach) { ret = dmabuf->ops->attach(dmabuf, attach); @@ -700,15 +708,19 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, dma_buf_is_dynamic(dmabuf)) { struct sg_table *sgt; - if (dma_buf_is_dynamic(attach->dmabuf)) + if (dma_buf_is_dynamic(attach->dmabuf)) { dma_resv_lock(attach->dmabuf->resv, NULL); + ret = dma_buf_pin(attach); + if (ret) + goto err_unlock; + } sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); if (!sgt) sgt = ERR_PTR(-ENOMEM); if (IS_ERR(sgt)) { ret = PTR_ERR(sgt); - goto err_unlock; + goto err_unpin; } if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_unlock(attach->dmabuf->resv); @@ -722,6 +734,10 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, kfree(attach); return ERR_PTR(ret); +err_unpin: + if (dma_buf_is_dynamic(attach->dmabuf)) + dma_buf_unpin(attach); + err_unlock: if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_unlock(attach->dmabuf->resv); @@ -742,7 +758,7 @@ EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach); struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev) { - return dma_buf_dynamic_attach(dmabuf, dev, false); + return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL); } EXPORT_SYMBOL_GPL(dma_buf_attach); @@ -765,8 +781,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir); - if (dma_buf_is_dynamic(attach->dmabuf)) + if (dma_buf_is_dynamic(attach->dmabuf)) { + dma_buf_unpin(attach); dma_resv_unlock(attach->dmabuf->resv); + } } dma_resv_lock(dmabuf->resv, NULL); @@ -779,6 +797,44 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) } EXPORT_SYMBOL_GPL(dma_buf_detach); +/** + * dma_buf_pin - Lock down the DMA-buf + * + * @attach: [in] attachment which should be pinned + * + * Returns: + * 0 on success, negative error code on failure. + */ +int dma_buf_pin(struct dma_buf_attachment *attach) +{ + struct dma_buf *dmabuf = attach->dmabuf; + int ret = 0; + + dma_resv_assert_held(dmabuf->resv); + + if (dmabuf->ops->pin) + ret = dmabuf->ops->pin(attach); + + return ret; +} +EXPORT_SYMBOL_GPL(dma_buf_pin); + +/** + * dma_buf_unpin - Remove lock from DMA-buf + * + * @attach: [in] attachment which should be unpinned + */ +void dma_buf_unpin(struct dma_buf_attachment *attach) +{ + struct dma_buf *dmabuf = attach->dmabuf; + + dma_resv_assert_held(dmabuf->resv); + + if (dmabuf->ops->unpin) + dmabuf->ops->unpin(attach); +} +EXPORT_SYMBOL_GPL(dma_buf_unpin); + /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the @@ -798,6 +854,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, enum dma_data_direction direction) { struct sg_table *sg_table; + int r; might_sleep(); @@ -819,13 +876,25 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return attach->sgt; } - if (dma_buf_is_dynamic(attach->dmabuf)) + if (dma_buf_is_dynamic(attach->dmabuf)) { dma_resv_assert_held(attach->dmabuf->resv); + if (!attach->importer_ops->move_notify || + !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) { + r = dma_buf_pin(attach); + if (r) + return ERR_PTR(r); + } + } sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); + if (IS_ERR(sg_table) && dma_buf_is_dynamic(attach->dmabuf) && + (!attach->importer_ops->move_notify || + !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))) + dma_buf_unpin(attach); + if (!IS_ERR(sg_table) && attach->dmabuf->ops->cache_sgt_mapping) { attach->sgt = sg_table; attach->dir = direction; @@ -864,9 +933,34 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, dma_resv_assert_held(attach->dmabuf->resv); attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); + + if (dma_buf_is_dynamic(attach->dmabuf) && + (!attach->importer_ops->move_notify || + !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))) + dma_buf_unpin(attach); } EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +/** + * dma_buf_move_notify - notify attachments that DMA-buf is moving + * + * @dmabuf: [in] buffer which is moving + * + * Informs all attachmenst that they need to destroy and recreated all their + * mappings. + */ +void dma_buf_move_notify(struct dma_buf *dmabuf) +{ + struct dma_buf_attachment *attach; + + dma_resv_assert_held(dmabuf->resv); + + list_for_each_entry(attach, &dmabuf->attachments, node) + if (attach->importer_ops && attach->importer_ops->move_notify) + attach->importer_ops->move_notify(attach); +} +EXPORT_SYMBOL_GPL(dma_buf_move_notify); + /** * DOC: cpu access * diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index a59cd47aa6c1..7cafc65fd76a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -412,6 +412,9 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf) return ERR_PTR(ret); } +static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = { +}; + /** * amdgpu_gem_prime_import - &drm_driver.gem_prime_import implementation * @dev: DRM device @@ -444,7 +447,8 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev, if (IS_ERR(obj)) return obj; - attach = dma_buf_dynamic_attach(dma_buf, dev->dev, true); + attach = dma_buf_dynamic_attach(dma_buf, dev->dev, + &amdgpu_dma_buf_attach_ops, NULL); if (IS_ERR(attach)) { drm_gem_object_put(obj); return ERR_CAST(attach); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index abf5459a5b9d..b38cea240b67 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -93,14 +93,41 @@ struct dma_buf_ops { */ void (*detach)(struct dma_buf *, struct dma_buf_attachment *); + /** + * @pin: + * + * This is called by dma_buf_pin and lets the exporter know that the + * DMA-buf can't be moved any more. + * + * This is called with the dmabuf->resv object locked. + * + * This callback is optional and should only be used in limited use + * cases like scanout and not for temporary pin operations. + * + * Returns: + * + * 0 on success, negative error code on failure. + */ + int (*pin)(struct dma_buf_attachment *attach); + + /** + * @unpin: + * + * This is called by dma_buf_unpin and lets the exporter know that the + * DMA-buf can be moved again. + * + * This is called with the dmabuf->resv object locked. + * + * This callback is optional. + */ + void (*unpin)(struct dma_buf_attachment *attach); + /** * @map_dma_buf: * * This is called by dma_buf_map_attachment() and is used to map a * shared &dma_buf into device address space, and it is mandatory. It - * can only be called if @attach has been called successfully. This - * essentially pins the DMA buffer into place, and it cannot be moved - * any more + * can only be called if @attach has been called successfully. * * This call may sleep, e.g. when the backing storage first needs to be * allocated, or moved to a location suitable for all currently attached @@ -141,9 +168,8 @@ struct dma_buf_ops { * * This is called by dma_buf_unmap_attachment() and should unmap and * release the &sg_table allocated in @map_dma_buf, and it is mandatory. - * It should also unpin the backing storage if this is the last mapping - * of the DMA buffer, it the exporter supports backing storage - * migration. + * For static dma_buf handling this might also unpins the backing + * storage if this is the last mapping of the DMA buffer. */ void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *, @@ -311,6 +337,34 @@ struct dma_buf { } cb_excl, cb_shared; }; +/** + * struct dma_buf_attach_ops - importer operations for an attachment + * @move_notify: [optional] notification that the DMA-buf is moving + * + * Attachment operations implemented by the importer. + */ +struct dma_buf_attach_ops { + /** + * @move_notify + * + * If this callback is provided the framework can avoid pinning the + * backing store while mappings exists. + * + * This callback is called with the lock of the reservation object + * associated with the dma_buf held and the mapping function must be + * called with this lock held as well. This makes sure that no mapping + * is created concurrently with an ongoing move operation. + * + * Mappings stay valid and are not directly affected by this callback. + * But the DMA-buf can now be in a different physical location, so all + * mappings should be destroyed and re-created as soon as possible. + * + * New mappings can be created after this callback returns, and will + * point to the new location of the DMA-buf. + */ + void (*move_notify)(struct dma_buf_attachment *attach); +}; + /** * struct dma_buf_attachment - holds device-buffer attachment data * @dmabuf: buffer for this attachment. @@ -319,8 +373,9 @@ struct dma_buf { * @sgt: cached mapping. * @dir: direction of cached mapping. * @priv: exporter specific attachment data. - * @dynamic_mapping: true if dma_buf_map/unmap_attachment() is called with the - * dma_resv lock held. + * @importer_ops: importer operations for this attachment, if provided + * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held. + * @importer_priv: importer specific attachment data. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -337,7 +392,8 @@ struct dma_buf_attachment { struct list_head node; struct sg_table *sgt; enum dma_data_direction dir; - bool dynamic_mapping; + const struct dma_buf_attach_ops *importer_ops; + void *importer_priv; void *priv; }; @@ -399,6 +455,7 @@ static inline void get_dma_buf(struct dma_buf *dmabuf) */ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf) { + /* TODO: switch to using pin/unpin functions as indicator. */ return dmabuf->ops->dynamic_mapping; } @@ -413,16 +470,19 @@ static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf) static inline bool dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach) { - return attach->dynamic_mapping; + return !!attach->importer_ops; } struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev); struct dma_buf_attachment * dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, - bool dynamic_mapping); + const struct dma_buf_attach_ops *importer_ops, + void *importer_priv); void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach); +int dma_buf_pin(struct dma_buf_attachment *attach); +void dma_buf_unpin(struct dma_buf_attachment *attach); struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info); -- 2.17.1

5 years, 2 months

2
8
0 0

Re: [Linaro-mm-sig] [PATCH v3 0/4] Support virtio cross-device resources

by Gerd Hoffmann

On Wed, Mar 11, 2020 at 08:20:00PM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1], with minor changes based on recent comments. It > is expected that this will be used to import virtio resources into the > virtio-video driver currently under discussion [2]. > > This patchset adds a new hook to dma-buf, for querying the dma-buf's > underlying virtio UUID. This hook is then plumbed through DRM PRIME > buffers, and finally implemented in virtgpu. Looks all fine to me. We should wait for the virtio protocol update (patch 3/4) being accepted into the virtio specification. When this is done I'll go commit this to drm-misc-next. cheers, Gerd

5 years, 2 months

1
0
0 0

[PATCH] MAINTAINERS: Better regex for dma_buf|fence|resv

by Daniel Vetter

We're getting some random other stuff that we're not really interested in, so match only word boundaries. Also avoid the capture group while at it. Suggested by Joe Perches. Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: Joe Perches <joe(a)perches.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- v2: No single quotes in MAINTAINERS (Joe) v3: Fix typo in commit message (Sam) --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3005be638c2c..ed6088a01bfe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5025,7 +5025,7 @@ F: include/linux/dma-buf* F: include/linux/reservation.h F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst -K: dma_(buf|fence|resv) +K: \bdma_(?:buf|fence|resv)\b T: git git://anongit.freedesktop.org/drm/drm-misc DMA-BUF HEAPS FRAMEWORK -- 2.25.1

5 years, 2 months

3
2
0 0

[PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

by Jason Ekstrand

Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on. This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times. There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages. The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video. Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> --- This is marked as an RFC because I intend it to start a discussion about how to solve a problem. The current patch compiles but that's it for now. I'll be writing IGT tests and Vulkan driver patches which exercise it over the next couple of days. In the mean time, feel free to tell me why you think this is a great and/or terrible idea. :-) --Jason drivers/dma-buf/dma-buf.c | 115 +++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 13 +++- 2 files changed, 126 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d4097856c86b..3845b87e209e 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -20,6 +20,7 @@ #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/dma-resv.h> #include <linux/mm.h> @@ -348,6 +349,114 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) return ret; } +static long dma_buf_wait_sync_file(struct dma_buf *dmabuf, + const void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fence = sync_file_get_fence(arg.fd); + if (!fence) + return -EINVAL; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + dma_resv_add_excl_fence(dmabuf->resv, fence); + } else { + dma_resv_add_shared_fence(dmabuf->resv, fence); + } + + return 0; +} + +static long dma_buf_signal_sync_file(struct dma_buf *dmabuf, + void __user *user_data) +{ + struct dma_buf_sync_file arg; + struct dma_fence *fence = NULL; + struct sync_file *sync_file; + int fd, ret; + + if (copy_from_user(&arg, user_data, sizeof(arg))) + return -EFAULT; + + if (arg.flags != 0 && arg.flags != DMA_BUF_SYNC_FILE_SYNC_WRITE) + return -EINVAL; + + fd = get_unused_fd_flags(O_CLOEXEC); + if (fd < 0) + return fd; + + if (arg.flags & DMA_BUF_SYNC_FILE_SYNC_WRITE) { + /* We need to include both the exclusive fence and all of + * the shared fences in our fence. + */ + struct dma_fence **fences = NULL; + unsigned i, num_fences = 0; + + ret = dma_resv_get_fences_rcu(dmabuf->resv, NULL, + &num_fences, &fences); + if (ret) + goto err_put_fd; + + if (num_fences == 0) { + fence = dma_fence_get_stub(); + } else if (num_fences == 1) { + fence = fences[0]; + kfree(fences); + } else { + struct dma_fence_array *fence_arr; + + fence_arr = dma_fence_array_create(num_fences, fences, + dma_fence_context_alloc(1), + 1, false); + if (!fence_arr) { + for (i = 0; i < num_fences; i++) + dma_fence_put(fences[i]); + kfree(fences); + ret = -ENOMEM; + goto err_put_fd; + } + + /* The fence array now owns fences_arr and our + * references to each of the individual fences. We + * only own a reference to the one array fence. + */ + fence = &fence_arr->base; + } + } else { + fence = dma_resv_get_excl_rcu(dmabuf->resv); + if (!fence) + fence = dma_fence_get_stub(); + } + + sync_file = sync_file_create(fence); + + dma_fence_put(fence); + + if (!sync_file) { + ret = -EINVAL; + goto err_put_fd; + } + + fd_install(fd, sync_file->file); + + arg.fd = fd; + if (copy_to_user(user_data, &arg, sizeof(arg))) + return -EFAULT; + + return 0; + +err_put_fd: + put_unused_fd(fd); + return ret; +} + static long dma_buf_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -390,6 +499,12 @@ static long dma_buf_ioctl(struct file *file, case DMA_BUF_SET_NAME: return dma_buf_set_name(dmabuf, (const char __user *)arg); + case DMA_BUF_IOCTL_WAIT_SYNC_FILE: + return dma_buf_wait_sync_file(dmabuf, (const void __user *)arg); + + case DMA_BUF_IOCTL_SIGNAL_SYNC_FILE: + return dma_buf_signal_sync_file(dmabuf, (void __user *)arg); + default: return -ENOTTY; } diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index dbc7092e04b5..825b9a913c89 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -37,8 +37,17 @@ struct dma_buf_sync { #define DMA_BUF_NAME_LEN 32 +struct dma_buf_sync_file { + __u32 flags; + __s32 fd; +}; + +#define DMA_BUF_SYNC_FILE_SYNC_WRITE (1 << 0) + #define DMA_BUF_BASE 'b' -#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) -#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync) +#define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *) +#define DMA_BUF_IOCTL_WAIT_SYNC_FILE _IOW(DMA_BUF_BASE, 2, struct dma_buf_sync) +#define DMA_BUF_IOCTL_SIGNAL_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct dma_buf_sync) #endif -- 2.24.1

5 years, 2 months

3
13
0 0

[PATCH] MAINTAINERS: Better regex for dma_buf|fence|resv

by Daniel Vetter

We're getting some random other stuff that we're not relly interested in, so match only word boundaries. Also avoid the capture group while at it. Suggested by Joe Perches. Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: Joe Perches <joe(a)perches.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- v2: No single quotes in MAINTAINERS (Joe) --- MAINTAINERS | 2 +- drivers/gpu/drm/drm_managed.c | 27 +++++++++++++++++---------- include/drm/drm_managed.h | 2 +- 3 files changed, 19 insertions(+), 12 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3005be638c2c..ed6088a01bfe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5025,7 +5025,7 @@ F: include/linux/dma-buf* F: include/linux/reservation.h F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst -K: dma_(buf|fence|resv) +K: \bdma_(?:buf|fence|resv)\b T: git git://anongit.freedesktop.org/drm/drm-misc DMA-BUF HEAPS FRAMEWORK diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c index 5148ef786c3b..c256c9679eb5 100644 --- a/drivers/gpu/drm/drm_managed.c +++ b/drivers/gpu/drm/drm_managed.c @@ -52,6 +52,12 @@ struct drmres { u8 __aligned(ARCH_KMALLOC_MINALIGN) data[]; }; +static void free_dr(struct drmres *dr) +{ + kfree_const(dr->node.name); + kfree(dr); +} + void drm_managed_release(struct drm_device *dev) { struct drmres *dr, *tmp; @@ -65,13 +71,13 @@ void drm_managed_release(struct drm_device *dev) dr->node.release(dev, dr->node.size ? *(void **)&dr->data : NULL); list_del(&dr->node.entry); - kfree(dr); + free_dr(dr); } drm_dbg_drmres(dev, "drmres release end\n"); } /* - * Always inline so that kmallc_track_caller tracks the actual interesting + * Always inline so that kmalloc_track_caller tracks the actual interesting * caller outside of drm_managed.c. */ static __always_inline struct drmres * alloc_dr(drmres_release_t release, @@ -120,7 +126,7 @@ static void add_dr(struct drm_device *dev, struct drmres *dr) /** * drmm_add_final_kfree - add release action for the final kfree() * @dev: DRM device - * @parent: pointer to the kmalloc allocation containing @dev + * @container: pointer to the kmalloc allocation containing @dev * * Since the allocation containing the struct &drm_device must be allocated * before it can be initialized with drm_dev_init() there's no way to allocate @@ -129,12 +135,13 @@ static void add_dr(struct drm_device *dev, struct drmres *dr) * will be released in the final drm_dev_put() for @dev, after all other release * actions installed through drmm_add_action() have been processed. */ -void drmm_add_final_kfree(struct drm_device *dev, void *parent) +void drmm_add_final_kfree(struct drm_device *dev, void *container) { WARN_ON(dev->managed.final_kfree); - WARN_ON(dev < (struct drm_device *) parent); - WARN_ON(dev + 1 >= (struct drm_device *) (parent + ksize(parent))); - dev->managed.final_kfree = parent; + WARN_ON(dev < (struct drm_device *) container); + WARN_ON(dev + 1 >= + (struct drm_device *) (container + ksize(container))); + dev->managed.final_kfree = container; } EXPORT_SYMBOL(drmm_add_final_kfree); @@ -154,7 +161,7 @@ int __drmm_add_action(struct drm_device *dev, return -ENOMEM; } - dr->node.name = name; + dr->node.name = kstrdup_const(name, GFP_KERNEL); if (data) { void_ptr = (void **)&dr->data; *void_ptr = data; @@ -212,7 +219,7 @@ void drmm_remove_action(struct drm_device *dev, if (WARN_ON(!dr)) return; - kfree(dr); + free_dr(dr); } EXPORT_SYMBOL(drmm_remove_action); @@ -300,6 +307,6 @@ void drmm_kfree(struct drm_device *dev, void *data) if (WARN_ON(!dr_match)) return; - kfree(dr_match); + free_dr(dr_match); } EXPORT_SYMBOL(drmm_kfree); diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h index af152cfb173c..e4021484c78d 100644 --- a/include/drm/drm_managed.h +++ b/include/drm/drm_managed.h @@ -51,7 +51,7 @@ void drmm_remove_action(struct drm_device *dev, drmres_release_t action, void *data); -void drmm_add_final_kfree(struct drm_device *dev, void *parent); +void drmm_add_final_kfree(struct drm_device *dev, void *container); void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc; -- 2.25.1

5 years, 2 months

1
0
0 0

[PATCH] MAINTAINERS: Better regex for dma_buf|fence|resv

by Daniel Vetter

We're getting some random other stuff that we're not relly interested in, so match only word boundaries. Also avoid the capture group while at it. Suggested by Joe Perches. Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: Joe Perches <joe(a)perches.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3005be638c2c..fc5d5aa53147 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5025,7 +5025,7 @@ F: include/linux/dma-buf* F: include/linux/reservation.h F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst -K: dma_(buf|fence|resv) +K: '\bdma_(?:buf|fence|resv)\b' T: git git://anongit.freedesktop.org/drm/drm-misc DMA-BUF HEAPS FRAMEWORK -- 2.25.1

5 years, 2 months

2
1
0 0

Re: [Linaro-mm-sig] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

by Christoph Hellwig

On Fri, Mar 13, 2020 at 09:17:42AM -0300, Jason Gunthorpe wrote: > On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote: > > On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: > > > The non-page scatterlist is also a big concern for RDMA as we have > > > drivers that want the page list, so even if we did as this series > > > contemplates I'd have still have to split the drivers and create the > > > notion of a dma-only SGL. > > > > The drivers I looked at want a list of IOVA address, aligned to the > > device "page size". What other data do drivers want? Execept for the > > software protocol stack drivers, which of couse need pages for the > > stack futher down. > > In principle it is possible to have just an aligned page list - > however the page size is variable, following certain rules, and today > the drivers still determine the correct page size largely on their > own. > > Some progress was made recently to consolidate this, but more is > needed. > > If the common code doesn't know the device page size in advance then > today's approach of sending largest possible dma mapped SGLs into the > device driver is best. The driver only has to do splitting. The point was that drivers don't need pages, drivers need IOVAs. In what form they are stuffed into the hardware is the drivers problem.

5 years, 2 months

2
2
0 0

Re: [Linaro-mm-sig] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

by Christoph Hellwig

On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. The drivers I looked at want a list of IOVA address, aligned to the device "page size". What other data do drivers want? Execept for the software protocol stack drivers, which of couse need pages for the stack futher down. > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory bio_vecs itself don't have the chaining, but the bios build around them do. But each entry can map a huge pile. If needed we could use the same chaining scheme we use for scatterlists for bio_vecs as well, but lets see if we really end up needing that. > So I'm guessing the path forward is something like > > - Add some generic dma_sg data structure and helper > - Add dma mapping code to go from pages to dma_sg That has been on my todo list for a while. All the DMA consolidatation is to prepare for that and we're finally getting close.

5 years, 2 months

2
1
0 0

Re: [Linaro-mm-sig] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

by Christian König

Am 12.03.20 um 15:19 schrieb Jason Gunthorpe: > On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote: >> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote: >>> But how should we then deal with all the existing interfaces which already >>> take a scatterlist/sg_table ? >>> >>> The whole DMA-buf design and a lot of drivers are build around >>> scatterlist/sg_table and to me that actually makes quite a lot of sense. >>> >> Replace them with a saner interface that doesn't take a scatterlist. >> At very least for new functionality like peer to peer DMA, but >> especially this code would also benefit from a general move away >> from the scatterlist. > If dma buf can do P2P I'd like to see support for consuming a dmabuf > in RDMA. That would indeed be awesome. > Looking at how.. there is an existing sgl based path starting > from get_user_pages through dma map to the drivers. (ib_umem) > > I can replace the driver part with something else (dma_sg), but not > until we get a way to DMA map pages directly into that something > else.. > > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. Yeah that's my concern as well. For GPU drivers I don't think we need the struct pages anywhere, but that might not be true for others. >>> I mean we could come up with a new structure for this, but to me that just >>> looks like reinventing the wheel. Especially since drivers need to be able >>> to handle both I/O to system memory and I/O to PCIe BARs. >> The structure for holding the struct page side of the scatterlist is >> called struct bio_vec, so far mostly used by the block and networking >> code. > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory > >> The structure for holding dma addresses doesn't really exist >> in a generic form, but would be an array of these structures: >> >> struct dma_sg { >> dma_addr_t addr; >> u32 len; >> }; > Same question, RDMA needs to represent gigabytes of pages in a DMA > list, we will need some generic way to handle that. I suspect GPU has > a similar need? Can it be accomidated in some generic dma_sg? Yes, we easily have ranges of >1GB. So I would certainly say u64 for the len here. > So I'm guessing the path forward is something like > > - Add some generic dma_sg data structure and helper > - Add dma mapping code to go from pages to dma_sg > - Rework RDMA to use dma_sg and the new dma mapping code > - Rework dmabuf to support dma mapping to a dma_sg > - Rework GPU drivers to use dma_sg > - Teach p2pdma to generate a dma_sg from a BAR page list > - This series > > ? Sounds pretty much like a plan to me, but unfortunately like a rather huge one. Because of this and cause I don't know if all drivers can live with dma_sg I'm not sure if we shouldn't have the switch from scatterlist to dma_sg separately to this peer2peer work. Christian. > > Jason

5 years, 2 months

1
0
0 0

P2P for DMA-buf

by Christian König

This is the third and final part of my series to start supporting P2P with DMA-buf. The implementation is straight forward, apart from a helper to aid constructing scatterlists without having struct pages we only add a new flag indicating that an DMA-buf importer can handle peer2peer. The exporter can then check if P2P is general possible using the pci_p2pdma_distance_many() function and if necessary can also clear the flag. The rest is an example how to implementing the necessary functionality into the amdgpu driver to setup scatterlists pointing to device memory. Please review and comment, Christian.

5 years, 2 months

4
13
0 0

Re: [Linaro-mm-sig] [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

by Christian König

Am 11.03.20 um 15:38 schrieb Jason Gunthorpe: > On Wed, Mar 11, 2020 at 03:33:01PM +0100, Christian König wrote: >> Am 11.03.20 um 15:04 schrieb Jason Gunthorpe: >>> On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote: >>>> Check if we can do peer2peer on the PCIe bus. >>>> >>>> Signed-off-by: Christian König <christian.koenig(a)amd.com> >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >>>> index aef12ee2f1e3..bbf67800c8a6 100644 >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >>>> @@ -38,6 +38,7 @@ >>>> #include <drm/amdgpu_drm.h> >>>> #include <linux/dma-buf.h> >>>> #include <linux/dma-fence-array.h> >>>> +#include <linux/pci-p2pdma.h> >>>> /** >>>> * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation >>>> @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf, >>>> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); >>>> int r; >>>> + if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0) >>>> + attach->peer2peer = false; >>>> + >>> Are there other related patches than this series? >>> >>> p2p dma mapping needs to be done in common code, in p2pdma.c - ie this >>> open coding is missing the bus_offset stuff, at least. >> Yeah, I'm aware of this. But I couldn't find a better way for now. > Well, it isn't optional :) > >>> I really do not want to see drivers open code this stuff. >>> >>> We already have a p2pdma API for handling the struct page case, so I >>> suggest adding some new p2pdma API to handle this for non-struct page >>> cases. >>> >>> ie some thing like: >>> >>> int 'p2pdma map bar'( >>> struct pci_device *source, >>> unsigned int source_bar_number, >>> struct pci_device *dest, >>> physaddr&len *array_of_offsets & length pairs into source bar, >>> struct scatterlist *output_sgl) >> Well that's exactly what I have to avoid since I don't have the array of >> offsets around and want to avoid constructing it. > Maybe it doesn't need an array of offsets - just a single offset and > callers can iterate the API? Yes, that would of course work as well. But I was assuming that p2pdma_map_bar() needs some state between those calls. > >> Similar problem for dma_map_resource(). My example does this on demand, but >> essentially we also have use cases where this is done only once. > I'm not sure if this is portable. Does any IOMMU HW need to know P2P > is happening to setup successfully? We currently support such a narrow > scope of HW for P2P.. On the AMD hardware I'm testing this calling dma_map_resource() already seems to work with IOMMU enabled. (Well at least it seemed so 6month ago when I last tested this). >> Ideally we would have some function to create an sgl based on some arbitrary >> collection of offsets and length inside a BAR. > Isn't that what I just proposed above ? Yes, just didn't thought that this would easily possible. I will double check the p2pdma code again. Thanks, Christian. > > Jason

5 years, 2 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

by Christian König

Am 11.03.20 um 15:04 schrieb Jason Gunthorpe: > On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote: >> Check if we can do peer2peer on the PCIe bus. >> >> Signed-off-by: Christian König <christian.koenig(a)amd.com> >> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >> index aef12ee2f1e3..bbf67800c8a6 100644 >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >> @@ -38,6 +38,7 @@ >> #include <drm/amdgpu_drm.h> >> #include <linux/dma-buf.h> >> #include <linux/dma-fence-array.h> >> +#include <linux/pci-p2pdma.h> >> >> /** >> * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation >> @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf, >> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); >> int r; >> >> + if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0) >> + attach->peer2peer = false; >> + > Are there other related patches than this series? > > p2p dma mapping needs to be done in common code, in p2pdma.c - ie this > open coding is missing the bus_offset stuff, at least. Yeah, I'm aware of this. But I couldn't find a better way for now. > I really do not want to see drivers open code this stuff. > > We already have a p2pdma API for handling the struct page case, so I > suggest adding some new p2pdma API to handle this for non-struct page > cases. > > ie some thing like: > > int 'p2pdma map bar'( > struct pci_device *source, > unsigned int source_bar_number, > struct pci_device *dest, > physaddr&len *array_of_offsets & length pairs into source bar, > struct scatterlist *output_sgl) Well that's exactly what I have to avoid since I don't have the array of offsets around and want to avoid constructing it. Similar problem for dma_map_resource(). My example does this on demand, but essentially we also have use cases where this is done only once. Ideally we would have some function to create an sgl based on some arbitrary collection of offsets and length inside a BAR. Regards, Christian. > > Jason

5 years, 2 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

by Christian König

Am 26.02.20 um 17:46 schrieb Bas Nieuwenhuizen: > On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand <jason(a)jlekstrand.net> wrote: >> On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter <daniel(a)ffwll.ch> wrote: >>> On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote: >>> [SNIP] >>>> Just imagine that you access some DMA-buf with a shader and that operation >>>> is presented as a fence on the DMA-bufs reservation object. And now you can >>>> go ahead and replace that fence and free up the memory. >>>> >>>> Tricking the Linux kernel into allocating page tables in that freed memory >>>> is trivial and that's basically it you can overwrite page tables with your >>>> shader and gain access to all of system memory :) >>>> >>>> What we could do is to always make sure that the added fences will complete >>>> later than the already existing ones, but that is also rather tricky to get >>>> right. I wouldn't do that if we don't have a rather big use case for this. >> Right. I thought about that but I'm still learning how dma_resv >> works. It'd be easy enough to make a fence array that contains both >> the old fence and the new fence and replace the old fence with that. >> What I don't know is the proper way to replace the exclusive fence >> safely. Some sort of atomic_cpxchg loop, perhaps? I presume there's >> some way of doing it properly because DRM drivers are doing it all the >> time. First of all you need to grab the lock of the dma_resv object or you can't replace the exclusive nor the shared ones. This way you don't need to do a atomic_cmpxchg or anything else and still guarantee correct ordering. > I think for an exclusive fence you may need to create a fence array > that includes the existing exclusive and shared fences in the dma_resv > combined with the added fence. Yes, that at least gives us the correct synchronization. > However, I'm not sure what the best way is to do garbage collection on > that so that we don't get an impossibly list of fence arrays. Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection. When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused. > (Note > the dma_resv has a lock that needs to be taken before adding an > exclusive fence, might be useful). Some code that does a thing like > this is __dma_resv_make_exclusive in > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c Wanted to move that into dma_resv.c for quite a while since there are quite a few other cases where we need this. Regards, Christian. > The other piece of the puzzle is that on the submit path this would > need something to ignore implicit fences. And there semantically the > question comes up whether it is safe for a driver to ignore exclusive > fences from another driver. (and then we have amdgpu which has its own > rules on exclusiveness of its shared fences based on the context. e.g. > the current option to ignore implicit fences for a buffer still syncs > on exclusive fences on the buffer).

5 years, 2 months

2
8
0 0

Re: [Linaro-mm-sig] KASAN: use-after-free Read in dmabuffs_dname

by Hillf Danton

On Fri, 06 Mar 2020 21:41:13 -0800 > syzbot found the following crash on: > > HEAD commit: 63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=11653ac3e00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=9833e26bab355358 > dashboard link: https://syzkaller.appspot.com/bug?extid=3643a18836bce555bff6 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > userspace arch: i386 > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+3643a18836bce555bff6(a)syzkaller.appspotmail.com > > ================================================================== > BUG: KASAN: use-after-free in dmabuffs_dname+0x4f4/0x560 drivers/dma-buf/dma-buf.c:48 > Read of size 8 at addr ffff8880a6b390e8 by task syz-executor.1/2394 > > CPU: 1 PID: 2394 Comm: syz-executor.1 Not tainted 5.6.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x197/0x210 lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 > __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506 > kasan_report+0x12/0x20 mm/kasan/common.c:641 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 > dmabuffs_dname+0x4f4/0x560 drivers/dma-buf/dma-buf.c:48 > tomoyo_realpath_from_path+0x165/0x660 security/tomoyo/realpath.c:259 > tomoyo_get_realpath security/tomoyo/file.c:151 [inline] > tomoyo_check_open_permission+0x2a3/0x3e0 security/tomoyo/file.c:771 > tomoyo_file_open security/tomoyo/tomoyo.c:319 [inline] > tomoyo_file_open+0xa9/0xd0 security/tomoyo/tomoyo.c:314 > security_file_open+0x71/0x300 security/security.c:1529 > do_dentry_open+0x37a/0x1380 fs/open.c:784 > vfs_open+0xa0/0xd0 fs/open.c:914 > do_last fs/namei.c:3490 [inline] > path_openat+0x12ee/0x3490 fs/namei.c:3607 > do_filp_open+0x192/0x260 fs/namei.c:3637 > do_sys_openat2+0x5eb/0x7e0 fs/open.c:1149 > do_sys_open+0xf2/0x180 fs/open.c:1165 > __do_compat_sys_open fs/open.c:1212 [inline] > __se_compat_sys_open fs/open.c:1210 [inline] > __ia32_compat_sys_open+0x79/0xb0 fs/open.c:1210 > do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] > do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > RIP: 0023:0xf7fd8e39 > Code: 1d 00 00 00 89 d3 5b 5e 5d c3 8b 04 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > RSP: 002b:00000000f5db2014 EFLAGS: 00000296 ORIG_RAX: 0000000000000005 > RAX: ffffffffffffffda RBX: 00000000f5db204c RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000c09 RDI: 00000000f5db204c > RBP: 00000000f5db2168 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > Allocated by task 2388: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > __kasan_kmalloc mm/kasan/common.c:515 [inline] > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:488 > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 > __do_kmalloc mm/slab.c:3656 [inline] > __kmalloc+0x163/0x770 mm/slab.c:3665 > kmalloc include/linux/slab.h:560 [inline] > kzalloc include/linux/slab.h:669 [inline] > dma_buf_export+0x24d/0xa80 drivers/dma-buf/dma-buf.c:533 > ion_alloc drivers/staging/android/ion/ion.c:386 [inline] > ion_ioctl+0x5a9/0xd20 drivers/staging/android/ion/ion.c:495 > compat_ptr_ioctl+0x6e/0xa0 fs/ioctl.c:804 > __do_compat_sys_ioctl fs/ioctl.c:857 [inline] > __se_compat_sys_ioctl fs/ioctl.c:808 [inline] > __ia32_compat_sys_ioctl+0x245/0x2c0 fs/ioctl.c:808 > do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] > do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > > Freed by task 2380: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > kasan_set_free_info mm/kasan/common.c:337 [inline] > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:476 > kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 > __cache_free mm/slab.c:3426 [inline] > kfree+0x10a/0x2c0 mm/slab.c:3757 > dma_buf_release+0x343/0x420 drivers/dma-buf/dma-buf.c:111 > __fput+0x2ff/0x890 fs/file_table.c:280 > ____fput+0x16/0x20 fs/file_table.c:313 > task_work_run+0x145/0x1c0 kernel/task_work.c:113 > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:164 > prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline] > syscall_return_slowpath arch/x86/entry/common.c:278 [inline] > do_syscall_32_irqs_on arch/x86/entry/common.c:352 [inline] > do_fast_syscall_32+0xbbd/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > > The buggy address belongs to the object at ffff8880a6b39000 > which belongs to the cache kmalloc-1k of size 1024 > The buggy address is located 232 bytes inside of > 1024-byte region [ffff8880a6b39000, ffff8880a6b39400) > The buggy address belongs to the page: > page:ffffea00029ace40 refcount:1 mapcount:0 mapping:ffff8880aa400c40 index:0x0 > flags: 0xfffe0000000200(slab) > raw: 00fffe0000000200 ffffea0002346b48 ffffea00022f49c8 ffff8880aa400c40 > raw: 0000000000000000 ffff8880a6b39000 0000000100000002 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff8880a6b38f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff8880a6b39000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > >ffff8880a6b39080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff8880a6b39100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff8880a6b39180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== Add a completion for dmabuf releaser to wait those who are either holding the resv lock or aquiring it. --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -334,6 +334,9 @@ struct dma_buf { __poll_t active; } cb_excl, cb_shared; + + atomic_t resv_user; + struct completion done; }; /** --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -45,11 +45,20 @@ static char *dmabuffs_dname(struct dentr size_t ret = 0; dmabuf = dentry->d_fsdata; + if (!dmabuf) + goto print_name; + + atomic_inc(&dmabuf->resv_user); + dma_resv_lock(dmabuf->resv, NULL); if (dmabuf->name) ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); dma_resv_unlock(dmabuf->resv); + if (atomic_dec_and_test(&dmabuf->resv_user)) + complete(&dmabuf->done); + +print_name: return dynamic_dname(dentry, buffer, buflen, "/%s:%s", dentry->d_name.name, ret > 0 ? name : ""); } @@ -85,6 +94,10 @@ static int dma_buf_release(struct inode return -EINVAL; dmabuf = file->private_data; + file->f_path.dentry->d_fsdata = NULL; + atomic_inc(&dmabuf->resv_user); + if (!atomic_dec_and_test(&dmabuf->resv_user)) + wait_for_completion(&dmabuf->done); BUG_ON(dmabuf->vmapping_counter); @@ -562,6 +575,7 @@ struct dma_buf *dma_buf_export(const str mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments); + init_completion(&dmabuf->done); mutex_lock(&db_list.lock); list_add(&dmabuf->list_node, &db_list.head);

5 years, 3 months

1
0
0 0

Re: [Linaro-mm-sig] [virtio-dev] [PATCH v2 4/4] drm/virtio: Support virtgpu exported resources

by Gerd Hoffmann

On Tue, Mar 03, 2020 at 11:42:22AM +0900, David Stevens wrote: > > cmd_p->hdr.ctx_id = > > > > Before this completion of this hypercall, this resource can be > > considered context local, while afterward it can be considered > > "exported". > > Maybe I'm misunderstanding render contexts, but exporting a resource > doesn't seem related to render contexts. It isn't indeed. Binding resources to contexts might need dma-buf imports/exports on the host side, but that is another story and not related to dma-buf exports inside the guest. cheers, Gerd

5 years, 3 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v2 4/4] drm/virtio: Support virtgpu exported resources

by Gerd Hoffmann

Hi, > + if (vgdev->has_resource_assign_uuid) { > + spin_lock(&vgdev->resource_export_lock); > + if (bo->uuid_state == UUID_NOT_INITIALIZED) { > + bo->uuid_state = UUID_INITIALIZING; > + needs_init = true; > + } > + spin_unlock(&vgdev->resource_export_lock); > + > + if (needs_init) { > + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, bo); You can submit a fenced command, then wait on the fence here. Removes the need for UUID_INITIALIZING. Also note that this function will be called only once, on the first export. When exporting the same object again drm will simply reuse the existing dmabuf. You can drop UUID_NOT_INITIALIZED and needs_init. So you are left with only two uuid_state states. You could turn uuid into a pointer, so it gets only allocated when needed. Also uuid == NULL can be used for "uuid not available" then. cheers, Gerd

5 years, 3 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH v2 1/4] dma-buf: add support for virtio exported objects

by Gerd Hoffmann

On Mon, Mar 02, 2020 at 09:15:21PM +0900, David Stevens wrote: > This change adds a new dma-buf operation that allows dma-bufs to be used > by virtio drivers to share exported objects. The new operation allows > the importing driver to query the exporting driver for the UUID which > identifies the underlying exported object. > > Signed-off-by: David Stevens <stevensd(a)chromium.org> > --- > drivers/dma-buf/dma-buf.c | 14 ++++++++++++++ > include/linux/dma-buf.h | 22 ++++++++++++++++++++++ > 2 files changed, 36 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..a04632284ec2 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,20 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +#ifdef CONFIG_VIRTIO > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) Hmm, I think I would drop the #ifdef cheers, Gerd

5 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig