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

Re: [Linaro-mm-sig] [PATCH] misc: sram: Add dma-heap-export reserved SRAM area type

by John Stultz

On Fri, Apr 24, 2020 at 3:27 PM Andrew F. Davis <afd(a)ti.com> wrote: > This new export type exposes to userspace the SRAM area as a DMA-Heap, > this allows for allocations as DMA-BUFs that can be consumed by various > DMA-BUF supporting devices. > > Signed-off-by: Andrew F. Davis <afd(a)ti.com> Nice! Very excited to have the first new heap (that didn't come with the initial patchset)! Overall looks good! I don't have any comment on the SRAM side of things, but a few minor questions/nits below. > diff --git a/drivers/misc/sram-dma-heap.c b/drivers/misc/sram-dma-heap.c > new file mode 100644 > index 000000000000..38df0397f294 > --- /dev/null > +++ b/drivers/misc/sram-dma-heap.c > @@ -0,0 +1,243 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * SRAM DMA-Heap userspace exporter > + * > + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > + * Andrew F. Davis <afd(a)ti.com> > + */ > + > +#include <linux/dma-mapping.h> > +#include <linux/err.h> > +#include <linux/genalloc.h> > +#include <linux/io.h> > +#include <linux/mm.h> > +#include <linux/scatterlist.h> > +#include <linux/slab.h> > +#include <linux/dma-buf.h> > +#include <linux/dma-heap.h> > + > +#include "sram.h" > + > +struct sram_dma_heap { > + struct dma_heap *heap; > + struct gen_pool *pool; > +}; > + > +struct sram_dma_heap_buffer { > + struct gen_pool *pool; > + struct list_head attachments; > + struct mutex attachments_lock; > + unsigned long len; > + void *vaddr; > + phys_addr_t paddr; > +}; > + > +struct dma_heap_attachment { > + struct device *dev; > + struct sg_table *table; > + struct list_head list; > +}; > + > +static int dma_heap_attach(struct dma_buf *dmabuf, > + struct dma_buf_attachment *attachment) > +{ > + struct sram_dma_heap_buffer *buffer = dmabuf->priv; > + struct dma_heap_attachment *a; > + struct sg_table *table; > + > + a = kzalloc(sizeof(*a), GFP_KERNEL); > + if (!a) > + return -ENOMEM; > + > + table = kmalloc(sizeof(*table), GFP_KERNEL); > + if (!table) { > + kfree(a); > + return -ENOMEM; > + } > + if (sg_alloc_table(table, 1, GFP_KERNEL)) { > + kfree(table); > + kfree(a); > + return -ENOMEM; > + } > + sg_set_page(table->sgl, pfn_to_page(PFN_DOWN(buffer->paddr)), buffer->len, 0); > + > + a->table = table; > + a->dev = attachment->dev; > + INIT_LIST_HEAD(&a->list); > + > + attachment->priv = a; > + > + mutex_lock(&buffer->attachments_lock); > + list_add(&a->list, &buffer->attachments); > + mutex_unlock(&buffer->attachments_lock); > + > + return 0; > +} > + > +static void dma_heap_detatch(struct dma_buf *dmabuf, > + struct dma_buf_attachment *attachment) > +{ > + struct sram_dma_heap_buffer *buffer = dmabuf->priv; > + struct dma_heap_attachment *a = attachment->priv; > + > + mutex_lock(&buffer->attachments_lock); > + list_del(&a->list); > + mutex_unlock(&buffer->attachments_lock); > + > + sg_free_table(a->table); > + kfree(a->table); > + kfree(a); > +} > + > +static struct sg_table *dma_heap_map_dma_buf(struct dma_buf_attachment *attachment, > + enum dma_data_direction direction) > +{ > + struct dma_heap_attachment *a = attachment->priv; > + struct sg_table *table = a->table; > + > + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents, > + direction, DMA_ATTR_SKIP_CPU_SYNC)) Might be nice to have a comment as to why you're using SKIP_CPU_SYNC and why it's safe. > + return ERR_PTR(-ENOMEM); > + > + return table; > +} > + > +static void dma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, > + struct sg_table *table, > + enum dma_data_direction direction) > +{ > + dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents, > + direction, DMA_ATTR_SKIP_CPU_SYNC); > +} > + > +static void dma_heap_dma_buf_release(struct dma_buf *dmabuf) > +{ > + struct sram_dma_heap_buffer *buffer = dmabuf->priv; > + > + gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len); > + kfree(buffer); > +} > + > +static int dma_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) > +{ > + struct sram_dma_heap_buffer *buffer = dmabuf->priv; > + int ret; > + > + /* SRAM mappings are not cached */ > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot); > + > + ret = vm_iomap_memory(vma, buffer->paddr, buffer->len); > + if (ret) > + pr_err("Could not map buffer to userspace\n"); > + > + return ret; > +} > + > +static void *dma_heap_vmap(struct dma_buf *dmabuf) > +{ > + struct sram_dma_heap_buffer *buffer = dmabuf->priv; > + > + return buffer->vaddr; > +} > + > +const struct dma_buf_ops sram_dma_heap_buf_ops = { > + .attach = dma_heap_attach, > + .detach = dma_heap_detatch, > + .map_dma_buf = dma_heap_map_dma_buf, > + .unmap_dma_buf = dma_heap_unmap_dma_buf, > + .release = dma_heap_dma_buf_release, > + .mmap = dma_heap_mmap, > + .vmap = dma_heap_vmap, > +}; No begin/end_cpu_access functions here? I'm guessing it's because you're always using SKIP_CPU_SYNC so it wouldn't do anything? A small comment in the code might help. > + > +static int sram_dma_heap_allocate(struct dma_heap *heap, > + unsigned long len, > + unsigned long fd_flags, > + unsigned long heap_flags) > +{ > + struct sram_dma_heap *sram_dma_heap = dma_heap_get_drvdata(heap); > + struct sram_dma_heap_buffer *buffer; > + > + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); > + struct dma_buf *dmabuf; > + int ret; > + > + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL); > + if (!buffer) > + return -ENOMEM; > + buffer->pool = sram_dma_heap->pool; > + INIT_LIST_HEAD(&buffer->attachments); > + mutex_init(&buffer->attachments_lock); > + buffer->len = len; > + > + buffer->vaddr = (void *)gen_pool_alloc(buffer->pool, buffer->len); > + if (!buffer->vaddr) { > + ret = -ENOMEM; > + goto free_buffer; > + } > + > + buffer->paddr = gen_pool_virt_to_phys(buffer->pool, (unsigned long)buffer->vaddr); > + if (buffer->paddr == -1) { > + ret = -ENOMEM; > + goto free_pool; > + } > + > + /* create the dmabuf */ > + exp_info.ops = &sram_dma_heap_buf_ops; > + exp_info.size = buffer->len; > + exp_info.flags = fd_flags; > + exp_info.priv = buffer; > + dmabuf = dma_buf_export(&exp_info); > + if (IS_ERR(dmabuf)) { > + ret = PTR_ERR(dmabuf); > + goto free_pool; > + } > + > + ret = dma_buf_fd(dmabuf, fd_flags); > + if (ret < 0) { > + dma_buf_put(dmabuf); > + /* just return, as put will call release and that will free */ > + return ret; > + } > + > + return ret; > + > +free_pool: > + gen_pool_free(buffer->pool, (unsigned long)buffer->vaddr, buffer->len); > +free_buffer: > + kfree(buffer); > + > + return ret; > +} > + > +static struct dma_heap_ops sram_dma_heap_ops = { > + .allocate = sram_dma_heap_allocate, > +}; > + > +int sram_dma_heap_export(struct sram_dev *sram, This is totally a bikeshed thing (feel free to ignore), but maybe sram_dma_heap_create() or _add() would be a better name to avoid folks mixing it up with the dmabuf exporter? > + struct sram_reserve *block, > + phys_addr_t start, > + struct sram_partition *part) > +{ > + struct sram_dma_heap *sram_dma_heap; > + struct dma_heap_export_info exp_info; > + > + dev_info(sram->dev, "Exporting SRAM pool '%s'\n", block->label); Again, shed issue: but for terminology consistency (at least in the dmabuf heaps space), maybe heap instead of pool? Thanks so much again for submitting this! -john

5 years, 7 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] dma-buf: heaps: Initialize during core instead of subsys

by John Stultz

On Fri, Apr 24, 2020 at 3:18 PM Andrew F. Davis <afd(a)ti.com> wrote: > > Some clients of DMA-Heaps probe earlier than subsys_initcall(), this > can cause issues when these clients call dma_heap_add() before the > core DMA-Heaps framework has initialized. DMA-Heaps should initialize > during core startup to get ahead of all users. > > Signed-off-by: Andrew F. Davis <afd(a)ti.com> No objection from me right off. Acked-by: John Stultz <john.stultz(a)linaro.org> thanks -john

5 years, 7 months

1
0
0 0

decruft the vmalloc API v2

by Christoph Hellwig

Hi all, Peter noticed that with some dumb luck you can toast the kernel address space with exported vmalloc symbols. I used this as an opportunity to decruft the vmalloc.c API and make it much more systematic. This also removes any chance to create vmalloc mappings outside the designated areas or using executable permissions from modules. Besides that it removes more than 300 lines of code. A git tree is also available here: git://git.infradead.org/users/hch/misc.git sanitize-vmalloc-api.2 Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/sanitize-vm… Changes since v1: - implement pgprot_nx for arm64 (Mark Rutland) - fix a patch description - properly pass pgprot to vmap in ion - add a new patch to fix vmap() API misuse - fix a vmap argument in x86 - two more vmalloc cleanups - cleanup use of the unmap_kernel_range API - rename ioremap_pbh to ioremap_phb

5 years, 8 months

3
32
0 0

[PATCH] staging: android: ion: Skip sync if not mapped

by Ørjan Eide

Only sync the sg-list of an Ion dma-buf attachment when the attachment is actually mapped on the device. dma-bufs may be synced at any time. It can be reached from user space via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when syncs may be attempted, and dma_buf_end_cpu_access() and dma_buf_begin_cpu_access() may not be paired. Since the sg_list's dma_address isn't set up until the buffer is used on the device, and dma_map_sg() is called on it, the dma_address will be NULL if sync is attempted on the dma-buf before it's mapped on a device. Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code")) this was a problem as the dma-api (at least the swiotlb_dma_ops on arm64) would use the potentially invalid dma_address. How that failed depended on how the device handled physical address 0. If 0 was a valid address to physical ram, that page would get flushed a lot, while the actual pages in the buffer would not get synced correctly. While if 0 is an invalid physical address it may cause a fault and trigger a crash. In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code"), as this moved the dma-api to use the page pointer in the sg_list, and (for Ion buffers at least) this will always be valid if the sg_list exists at all. But, this issue is re-introduced in v5.3 with commit 449fa54d6815 ("dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old behaviour and picks the dma_address that may be invalid. dma-buf core doesn't ensure that the buffer is mapped on the device, and thus have a valid sg_list, before calling the exporter's begin_cpu_access. Signed-off-by: Ørjan Eide <orjan.eide(a)arm.com> --- drivers/staging/android/ion/ion.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) This seems to be part of a bigger issue where dma-buf exporters assume that their dma-buf begin_cpu_access and end_cpu_access callbacks have a certain guaranteed behavior, which isn't ensured by dma-buf core. This patch fixes this in ion only, but it also needs to be fixed for other exporters, either handled like this in each exporter, or in dma-buf core before calling into the exporters. diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 38b51eace4f9..7b752ba0cb6d 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -173,6 +173,7 @@ struct ion_dma_buf_attachment { struct device *dev; struct sg_table *table; struct list_head list; + bool mapped:1; }; static int ion_dma_buf_attach(struct dma_buf *dmabuf, @@ -195,6 +196,7 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf, a->table = table; a->dev = attachment->dev; INIT_LIST_HEAD(&a->list); + a->mapped = false; attachment->priv = a; @@ -231,6 +233,8 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment, direction)) return ERR_PTR(-ENOMEM); + a->mapped = true; + return table; } @@ -238,6 +242,10 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment, struct sg_table *table, enum dma_data_direction direction) { + struct ion_dma_buf_attachment *a = attachment->priv; + + a->mapped = false; + dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction); } @@ -297,6 +305,8 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, mutex_lock(&buffer->lock); list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents, direction); } @@ -320,6 +330,8 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf, mutex_lock(&buffer->lock); list_for_each_entry(a, &buffer->attachments, list) { + if (!a->mapped) + continue; dma_sync_sg_for_device(a->dev, a->table->sgl, a->table->nents, direction); } -- 2.17.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

6
12
0 0

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

by Minchan Kim

Hi Sergey, On Fri, Apr 10, 2020 at 11:38:45AM +0900, Sergey Senozhatsky wrote: > On (20/04/09 10:08), Minchan Kim wrote: > > > > Even though I don't know how many usecase we have using zsmalloc as > > > > module(I heard only once by dumb reason), it could affect existing > > > > users. Thus, please include concrete explanation in the patch to > > > > justify when the complain occurs. > > > > > > The justification is 'we can unexport functions that have no sane reason > > > of being exported in the first place'. > > > > > > The Changelog pretty much says that. > > > > Okay, I hope there is no affected user since this patch. > > If there are someone, they need to provide sane reason why they want > > to have zsmalloc as module. > > I'm one of those who use zsmalloc as a module - mainly because I use zram > as a compressing general purpose block device, not as a swap device. > I create zram0, mkfs, mount, checkout and compile code, once done - > umount, rmmod. This reduces the number of writes to SSD. Some people use > tmpfs, but zram device(-s) can be much larger in size. That's a niche use > case and I'm not against the patch. It doesn't mean we couldn't use zsmalloc as module any longer. It means we couldn't use zsmalloc as module with pgtable mapping whcih was little bit faster on microbenchmark in some architecutre(However, I usually temped to remove it since it had several problems). However, we could still use zsmalloc as module as copy way instead of pgtable mapping. Thus, if someone really want to rollback the feature, they should provide reasonable reason why it doesn't work for them. "A little fast" wouldn't be enough to exports deep internal to the module. Thanks.

5 years, 8 months

2
2
0 0

decruft the vmalloc API

by Christoph Hellwig

Hi all, Peter noticed that with some dumb luck you can toast the kernel address space with exported vmalloc symbols. I used this as an opportunity to decruft the vmalloc.c API and make it much more systematic. This also removes any chance to create vmalloc mappings outside the designated areas or using executable permissions from modules. Besides that it removes more than 300 lines of code. A git tree is also available here: git://git.infradead.org/users/hch/misc.git sanitize-vmalloc-api Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/sanitize-vm…

5 years, 8 months

10
50
0 0

[PATCH v2] staging: android: ion: use macro DEFINE_DEBUGFS_ATTRIBUTE to define debugfs fops

by R Veera Kumar

It is more clear to use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs file operation rather than DEFINE_SIMPLE_ATTRIBUTE. Found using coccinelle. Signed-off-by: R Veera Kumar <vkor(a)vkten.in> --- Changes in v2: - Give correct explanation for patch - Adjust git commit tag and msg accordingly --- drivers/staging/android/ion/ion.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 38b51eace4f9..dbe4018a6f83 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -554,8 +554,8 @@ static int debug_shrink_get(void *data, u64 *val) return 0; } -DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get, - debug_shrink_set, "%llu\n"); +DEFINE_DEBUGFS_ATTRIBUTE(debug_shrink_fops, debug_shrink_get, + debug_shrink_set, "%llu\n"); void ion_device_add_heap(struct ion_heap *heap) { -- 2.20.1

5 years, 8 months

2
1
0 0

[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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 months

4
13
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig