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

Re: [PATCH] [Draft]: media: videobuf2-dma-heap: add a vendor defined memory runtine

by ayaka

Sent from my iPad > On Aug 1, 2022, at 5:46 PM, Tomasz Figa <tfiga(a)chromium.org> wrote: > > CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe. > > >> On Mon, Aug 1, 2022 at 3:44 PM Hsia-Jun Li <Randy.Li(a)synaptics.com> wrote: >>> On 8/1/22 14:19, Tomasz Figa wrote: >> Hello Tomasz >>> ?Hi Randy, >>> On Mon, Aug 1, 2022 at 5:21 AM <ayaka(a)soulik.info> wrote: >>>> From: Randy Li <ayaka(a)soulik.info> >>>> This module is still at a early stage, I wrote this for showing what >>>> APIs we need here. >>>> Let me explain why we need such a module here. >>>> If you won't allocate buffers from a V4L2 M2M device, this module >>>> may not be very useful. I am sure the most of users won't know a >>>> device would require them allocate buffers from a DMA-Heap then >>>> import those buffers into a V4L2's queue. >>>> Then the question goes back to why DMA-Heap. From the Android's >>>> description, we know it is about the copyright's DRM. >>>> When we allocate a buffer in a DMA-Heap, it may register that buffer >>>> in the trusted execution environment so the firmware which is running >>>> or could only be acccesed from there could use that buffer later. >>>> The answer above leads to another thing which is not done in this >>>> version, the DMA mapping. Although in some platforms, a DMA-Heap >>>> responses a IOMMU device as well. For the genernal purpose, we would >>>> be better assuming the device mapping should be done for each device >>>> itself. The problem here we only know alloc_devs in those DMAbuf >>>> methods, which are DMA-heaps in my design, the device from the queue >>>> is not enough, a plane may requests another IOMMU device or table >>>> for mapping. >>>> Signed-off-by: Randy Li <ayaka(a)soulik.info> >>>> --- >>>> drivers/media/common/videobuf2/Kconfig | 6 + >>>> drivers/media/common/videobuf2/Makefile | 1 + >>>> .../common/videobuf2/videobuf2-dma-heap.c | 350 ++++++++++++++++++ >>>> include/media/videobuf2-dma-heap.h | 30 ++ >>>> 4 files changed, 387 insertions(+) >>>> create mode 100644 drivers/media/common/videobuf2/videobuf2-dma-heap.c >>>> create mode 100644 include/media/videobuf2-dma-heap.h >>> First of all, thanks for the series. >>> Possibly a stupid question, but why not just allocate the DMA-bufs >>> directly from the DMA-buf heap device in the userspace and just import >>> the buffers to the V4L2 device using V4L2_MEMORY_DMABUF? >> Sometimes the allocation policy could be very complex, let's suppose a >> multiple planes pixel format enabling with frame buffer compression. >> Its luma, chroma data could be allocated from a pool which is delegated >> for large buffers while its metadata would come from a pool which many >> users could take some few slices from it(likes system pool). >> Then when we have a new users knowing nothing about this platform, if we >> just configure the alloc_devs in each queues well. The user won't need >> to know those complex rules. >> The real situation could be more complex, Samsung MFC's left and right >> banks could be regarded as two pools, many devices would benefit from >> this either from the allocation times or the security buffers policy. >> In our design, when we need to do some security decoding(DRM video), >> codecs2 would allocate buffers from the pool delegated for that. While >> the non-DRM video, users could not care about this. > > I'm a little bit surprised about this, because on Android all the > graphics buffers are allocated from the system IAllocator and imported > to the specific devices. In the non-tunnel mode, yes it is. While the tunnel mode is completely vendor defined. Neither HWC nor codec2 cares about where the buffers coming from, you could do what ever you want. Besides there are DRM video in GNU Linux platform, I heard the webkit has made huge effort here and Playready is one could work in non-Android Linux. > Would it make sense to instead extend the UAPI to expose enough > information about the allocation requirements to the userspace, so it > can allocate correctly? Yes, it could. But as I said it would need the users to do more works. > My reasoning here is that it's not a driver's decision to allocate > from a DMA-buf heap (and which one) or not. It's the userspace which > knows that, based on the specific use case that it wants to fulfill. Although I would like to let the users decide that, users just can’t do that which would violate the security rules in some platforms. For example, video codec and display device could only access a region of memory, any other device or trusted apps can’t access it. Users have to allocate the buffer from the pool the vendor decided. So why not we offer a quick way that users don’t need to try and error. > Also, FWIW, dma_heap_ioctl_allocate() is a static function not exposed > to other kernel modules: > https://urldefense.proofpoint.com/v2/url?u=https-3A__elixir.bootlin.com_lin… I may forget to mention that you need two extra patches from Linaro that export those API(original version is actually out of time). Besides Android kernel did have the two kAPI I need here. Actually I need more APIs from DMA-heap to archive those things in TODO list. > By the way, the MFC left/right port requirement was gone long ago, it > was only one of the earliest Exynos SoCs which required that. Yes, MFCv5 or v6 right. I just want mention that the world has any possible, vendor always has its own reason. > Best regards, > Tomasz > >>> Best regards, >>> Tomasz >>>> diff --git a/drivers/media/common/videobuf2/Kconfig b/drivers/media/common/videobuf2/Kconfig >>>> index d2223a12c95f..02235077f07e 100644 >>>> --- a/drivers/media/common/videobuf2/Kconfig >>>> +++ b/drivers/media/common/videobuf2/Kconfig >>>> @@ -30,3 +30,9 @@ config VIDEOBUF2_DMA_SG >>>> config VIDEOBUF2_DVB >>>> tristate >>>> select VIDEOBUF2_CORE >>>> + >>>> +config VIDEOBUF2_DMA_HEAP >>>> + tristate >>>> + select VIDEOBUF2_CORE >>>> + select VIDEOBUF2_MEMOPS >>>> + select DMABUF_HEAPS >>>> diff --git a/drivers/media/common/videobuf2/Makefile b/drivers/media/common/videobuf2/Makefile >>>> index a6fe3f304685..7fe65f93117f 100644 >>>> --- a/drivers/media/common/videobuf2/Makefile >>>> +++ b/drivers/media/common/videobuf2/Makefile >>>> @@ -10,6 +10,7 @@ endif >>>> # (e. g. LC_ALL=C sort Makefile) >>>> obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-common.o >>>> obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o >>>> +obj-$(CONFIG_VIDEOBUF2_DMA_HEAP) += videobuf2-dma-heap.o >>>> obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o >>>> obj-$(CONFIG_VIDEOBUF2_DVB) += videobuf2-dvb.o >>>> obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o >>>> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-heap.c b/drivers/media/common/videobuf2/videobuf2-dma-heap.c >>>> new file mode 100644 >>>> index 000000000000..377b82ab8f5a >>>> --- /dev/null >>>> +++ b/drivers/media/common/videobuf2/videobuf2-dma-heap.c >>>> @@ -0,0 +1,350 @@ >>>> +/* >>>> + * Copyright (C) 2022 Randy Li <ayaka(a)soulik.info> >>>> + * >>>> + * This software is licensed under the terms of the GNU General Public >>>> + * License version 2, as published by the Free Software Foundation, and >>>> + * may be copied, distributed, and modified under those terms. >>>> + * >>>> + * This program is distributed in the hope that it will be useful, >>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>> + * GNU General Public License for more details. >>>> + * >>>> + */ >>>> + >>>> +#include <linux/dma-buf.h> >>>> +#include <linux/dma-heap.h> >>>> +#include <linux/refcount.h> >>>> +#include <linux/scatterlist.h> >>>> +#include <linux/sched.h> >>>> +#include <linux/slab.h> >>>> +#include <linux/dma-mapping.h> >>>> + >>>> +#include <media/videobuf2-v4l2.h> >>>> +#include <media/videobuf2-memops.h> >>>> +#include <media/videobuf2-dma-heap.h> >>>> + >>>> +struct vb2_dmaheap_buf { >>>> + struct device *dev; >>>> + void *vaddr; >>>> + unsigned long size; >>>> + struct dma_buf *dmabuf; >>>> + dma_addr_t dma_addr; >>>> + unsigned long attrs; >>>> + enum dma_data_direction dma_dir; >>>> + struct sg_table *dma_sgt; >>>> + >>>> + /* MMAP related */ >>>> + struct vb2_vmarea_handler handler; >>>> + refcount_t refcount; >>>> + >>>> + /* DMABUF related */ >>>> + struct dma_buf_attachment *db_attach; >>>> +}; >>>> + >>>> +/*********************************************/ >>>> +/* callbacks for all buffers */ >>>> +/*********************************************/ >>>> + >>>> +void *vb2_dmaheap_cookie(struct vb2_buffer *vb, void *buf_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + >>>> + return &buf->dma_addr; >>>> +} >>>> + >>>> +static void *vb2_dmaheap_vaddr(struct vb2_buffer *vb, void *buf_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + struct iosys_map map; >>>> + >>>> + if (buf->vaddr) >>>> + return buf->vaddr; >>>> + >>>> + if (buf->db_attach) { >>>> + if (!dma_buf_vmap(buf->db_attach->dmabuf, &map)) >>>> + buf->vaddr = map.vaddr; >>>> + } >>>> + >>>> + return buf->vaddr; >>>> +} >>>> + >>>> +static unsigned int vb2_dmaheap_num_users(void *buf_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + >>>> + return refcount_read(&buf->refcount); >>>> +} >>>> + >>>> +static void vb2_dmaheap_prepare(void *buf_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + >>>> + /* TODO: DMABUF exporter will flush the cache for us */ >>>> + if (buf->db_attach) >>>> + return; >>>> + >>>> + dma_buf_end_cpu_access(buf->dmabuf, buf->dma_dir); >>>> +} >>>> + >>>> +static void vb2_dmaheap_finish(void *buf_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + >>>> + /* TODO: DMABUF exporter will flush the cache for us */ >>>> + if (buf->db_attach) >>>> + return; >>>> + >>>> + dma_buf_begin_cpu_access(buf->dmabuf, buf->dma_dir); >>>> +} >>>> + >>>> +/*********************************************/ >>>> +/* callbacks for MMAP buffers */ >>>> +/*********************************************/ >>>> + >>>> +void vb2_dmaheap_put(void *buf_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + >>>> + if (!refcount_dec_and_test(&buf->refcount)) >>>> + return; >>>> + >>>> + dma_buf_put(buf->dmabuf); >>>> + >>>> + put_device(buf->dev); >>>> + kfree(buf); >>>> +} >>>> + >>>> +static void *vb2_dmaheap_alloc(struct vb2_buffer *vb, >>>> + struct device *dev, >>>> + unsigned long size) >>>> +{ >>>> + struct vb2_queue *q = vb->vb2_queue; >>>> + struct dma_heap *heap; >>>> + struct vb2_dmaheap_buf *buf; >>>> + const char *heap_name; >>>> + int ret; >>>> + >>>> + if (WARN_ON(!dev)) >>>> + return ERR_PTR(-EINVAL); >>>> + >>>> + heap_name = dev_name(dev); >>>> + if (!heap_name) >>>> + return ERR_PTR(-EINVAL); >>>> + >>>> + heap = dma_heap_find(heap_name); >>>> + if (!heap) { >>>> + dev_err(dev, "is not a DMA-heap device\n"); >>>> + return ERR_PTR(-EINVAL); >>>> + } >>>> + >>>> + buf = kzalloc(sizeof *buf, GFP_KERNEL); >>>> + if (!buf) >>>> + return ERR_PTR(-ENOMEM); >>>> + >>>> + /* Prevent the device from being released while the buffer is used */ >>>> + buf->dev = get_device(dev); >>>> + buf->attrs = vb->vb2_queue->dma_attrs; >>>> + buf->dma_dir = vb->vb2_queue->dma_dir; >>>> + >>>> + /* TODO: heap flags */ >>>> + ret = dma_heap_buffer_alloc(heap, size, 0, 0); >>>> + if (ret < 0) { >>>> + dev_err(dev, "is not a DMA-heap device\n"); >>>> + put_device(buf->dev); >>>> + kfree(buf); >>>> + return ERR_PTR(ret); >>>> + } >>>> + buf->dmabuf = dma_buf_get(ret); >>>> + >>>> + /* FIXME */ >>>> + buf->dma_addr = 0; >>>> + >>>> + if ((q->dma_attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0) >>>> + buf->vaddr = buf->dmabuf; >>>> + >>>> + buf->handler.refcount = &buf->refcount; >>>> + buf->handler.put = vb2_dmaheap_put; >>>> + buf->handler.arg = buf; >>>> + >>>> + refcount_set(&buf->refcount, 1); >>>> + >>>> + return buf; >>>> +} >>>> + >>>> +static int vb2_dmaheap_mmap(void *buf_priv, struct vm_area_struct *vma) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + int ret; >>>> + >>>> + if (!buf) { >>>> + printk(KERN_ERR "No buffer to map\n"); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + vma->vm_flags &= ~VM_PFNMAP; >>>> + >>>> + ret = dma_buf_mmap(buf->dmabuf, vma, 0); >>>> + if (ret) { >>>> + pr_err("Remapping memory failed, error: %d\n", ret); >>>> + return ret; >>>> + } >>>> + vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; >>>> + vma->vm_private_data = &buf->handler; >>>> + vma->vm_ops = &vb2_common_vm_ops; >>>> + >>>> + vma->vm_ops->open(vma); >>>> + >>>> + pr_debug("%s: mapped memid 0x%08lx at 0x%08lx, size %ld\n", >>>> + __func__, (unsigned long)buf->dma_addr, vma->vm_start, >>>> + buf->size); >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +/*********************************************/ >>>> +/* DMABUF ops for exporters */ >>>> +/*********************************************/ >>>> + >>>> +static struct dma_buf *vb2_dmaheap_get_dmabuf(struct vb2_buffer *vb, >>>> + void *buf_priv, >>>> + unsigned long flags) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = buf_priv; >>>> + struct dma_buf *dbuf; >>>> + >>>> + dbuf = buf->dmabuf; >>>> + >>>> + return dbuf; >>>> +} >>>> + >>>> +/*********************************************/ >>>> +/* callbacks for DMABUF buffers */ >>>> +/*********************************************/ >>>> + >>>> +static int vb2_dmaheap_map_dmabuf(void *mem_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = mem_priv; >>>> + struct sg_table *sgt; >>>> + >>>> + if (WARN_ON(!buf->db_attach)) { >>>> + pr_err("trying to pin a non attached buffer\n"); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + if (WARN_ON(buf->dma_sgt)) { >>>> + pr_err("dmabuf buffer is already pinned\n"); >>>> + return 0; >>>> + } >>>> + >>>> + /* get the associated scatterlist for this buffer */ >>>> + sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir); >>>> + if (IS_ERR(sgt)) { >>>> + pr_err("Error getting dmabuf scatterlist\n"); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + buf->dma_addr = sg_dma_address(sgt->sgl); >>>> + buf->dma_sgt = sgt; >>>> + buf->vaddr = NULL; >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +static void vb2_dmaheap_unmap_dmabuf(void *mem_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = mem_priv; >>>> + struct sg_table *sgt = buf->dma_sgt; >>>> + struct iosys_map map = IOSYS_MAP_INIT_VADDR(buf->vaddr); >>>> + >>>> + if (WARN_ON(!buf->db_attach)) { >>>> + pr_err("trying to unpin a not attached buffer\n"); >>>> + return; >>>> + } >>>> + >>>> + if (WARN_ON(!sgt)) { >>>> + pr_err("dmabuf buffer is already unpinned\n"); >>>> + return; >>>> + } >>>> + >>>> + if (buf->vaddr) { >>>> + dma_buf_vunmap(buf->db_attach->dmabuf, &map); >>>> + buf->vaddr = NULL; >>>> + } >>>> + dma_buf_unmap_attachment(buf->db_attach, sgt, buf->dma_dir); >>>> + >>>> + buf->dma_addr = 0; >>>> + buf->dma_sgt = NULL; >>>> +} >>>> + >>>> +static void vb2_dmaheap_detach_dmabuf(void *mem_priv) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf = mem_priv; >>>> + >>>> + /* if vb2 works correctly you should never detach mapped buffer */ >>>> + if (WARN_ON(buf->dma_addr)) >>>> + vb2_dmaheap_unmap_dmabuf(buf); >>>> + >>>> + /* detach this attachment */ >>>> + dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach); >>>> + kfree(buf); >>>> +} >>>> + >>>> +static void *vb2_dmaheap_attach_dmabuf(struct vb2_buffer *vb, struct device *dev, >>>> + struct dma_buf *dbuf, unsigned long size) >>>> +{ >>>> + struct vb2_dmaheap_buf *buf; >>>> + struct dma_buf_attachment *dba; >>>> + >>>> + if (dbuf->size < size) >>>> + return ERR_PTR(-EFAULT); >>>> + >>>> + if (WARN_ON(!dev)) >>>> + return ERR_PTR(-EINVAL); >>>> + /* >>>> + * TODO: A better way to check whether the buffer is coming >>>> + * from this heap or this heap could accept this buffer >>>> + */ >>>> + if (strcmp(dbuf->exp_name, dev_name(dev))) >>>> + return ERR_PTR(-EINVAL); >>>> + >>>> + buf = kzalloc(sizeof(*buf), GFP_KERNEL); >>>> + if (!buf) >>>> + return ERR_PTR(-ENOMEM); >>>> + >>>> + buf->dev = dev; >>>> + /* create attachment for the dmabuf with the user device */ >>>> + dba = dma_buf_attach(dbuf, buf->dev); >>>> + if (IS_ERR(dba)) { >>>> + pr_err("failed to attach dmabuf\n"); >>>> + kfree(buf); >>>> + return dba; >>>> + } >>>> + >>>> + buf->dma_dir = vb->vb2_queue->dma_dir; >>>> + buf->size = size; >>>> + buf->db_attach = dba; >>>> + >>>> + return buf; >>>> +} >>>> + >>>> +const struct vb2_mem_ops vb2_dmaheap_memops = { >>>> + .alloc = vb2_dmaheap_alloc, >>>> + .put = vb2_dmaheap_put, >>>> + .get_dmabuf = vb2_dmaheap_get_dmabuf, >>>> + .cookie = vb2_dmaheap_cookie, >>>> + .vaddr = vb2_dmaheap_vaddr, >>>> + .prepare = vb2_dmaheap_prepare, >>>> + .finish = vb2_dmaheap_finish, >>>> + .map_dmabuf = vb2_dmaheap_map_dmabuf, >>>> + .unmap_dmabuf = vb2_dmaheap_unmap_dmabuf, >>>> + .attach_dmabuf = vb2_dmaheap_attach_dmabuf, >>>> + .detach_dmabuf = vb2_dmaheap_detach_dmabuf, >>>> + .num_users = vb2_dmaheap_num_users, >>>> + .mmap = vb2_dmaheap_mmap, >>>> +}; >>>> + >>>> +MODULE_DESCRIPTION("DMA-Heap memory handling routines for videobuf2"); >>>> +MODULE_AUTHOR("Randy Li <ayaka(a)soulik.info>"); >>>> +MODULE_LICENSE("GPL"); >>>> +MODULE_IMPORT_NS(DMA_BUF); >>>> diff --git a/include/media/videobuf2-dma-heap.h b/include/media/videobuf2-dma-heap.h >>>> new file mode 100644 >>>> index 000000000000..fa057f67d6e9 >>>> --- /dev/null >>>> +++ b/include/media/videobuf2-dma-heap.h >>>> @@ -0,0 +1,30 @@ >>>> +/* >>>> + * Copyright (C) 2022 Randy Li <ayaka(a)soulik.info> >>>> + * >>>> + * This software is licensed under the terms of the GNU General Public >>>> + * License version 2, as published by the Free Software Foundation, and >>>> + * may be copied, distributed, and modified under those terms. >>>> + * >>>> + * This program is distributed in the hope that it will be useful, >>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>>> + * GNU General Public License for more details. >>>> + * >>>> + */ >>>> + >>>> +#ifndef _MEDIA_VIDEOBUF2_DMA_HEAP_H >>>> +#define _MEDIA_VIDEOBUF2_DMA_HEAP_H >>>> + >>>> +#include <media/videobuf2-v4l2.h> >>>> +#include <linux/dma-mapping.h> >>>> + >>>> +static inline dma_addr_t >>>> +vb2_dmaheap_plane_dma_addr(struct vb2_buffer *vb, unsigned int plane_no) >>>> +{ >>>> + dma_addr_t *addr = vb2_plane_cookie(vb, plane_no); >>>> + >>>> + return *addr; >>>> +} >>>> + >>>> +extern const struct vb2_mem_ops vb2_dmaheap_memops; >>>> +#endif >>>> -- >>>> 2.17.1 >> -- >> Hsia-Jun(Randy) Li

2 years, 9 months

3
7
0 0

[PATCH rc] RDMA: Handle the return code from dma_resv_wait_timeout() properly

by Jason Gunthorpe

ib_umem_dmabuf_map_pages() returns 0 on success and -ERRNO on failure. dma_resv_wait_timeout() uses a different scheme: * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or * greater than zero on success. This results in ib_umem_dmabuf_map_pages() being non-functional as a positive return will be understood to be an error by drivers. Fixes: f30bceab16d1 ("RDMA: use dma_resv_wait() instead of extracting the fence") Cc: stable(a)kernel.org Tested-by: Maor Gottlieb <maorg(a)nvidia.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/infiniband/core/umem_dmabuf.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) Oded, I assume the Habana driver will hit this as well - does this mean you are not testing upstream kernels? diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c index fce80a4a5147cd..04c04e6d24c358 100644 --- a/drivers/infiniband/core/umem_dmabuf.c +++ b/drivers/infiniband/core/umem_dmabuf.c @@ -18,6 +18,7 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) struct scatterlist *sg; unsigned long start, end, cur = 0; unsigned int nmap = 0; + long ret; int i; dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv); @@ -67,9 +68,14 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) * may be not up-to-date. Wait for the exporter to finish * the migration. */ - return dma_resv_wait_timeout(umem_dmabuf->attach->dmabuf->resv, + ret = dma_resv_wait_timeout(umem_dmabuf->attach->dmabuf->resv, DMA_RESV_USAGE_KERNEL, false, MAX_SCHEDULE_TIMEOUT); + if (ret < 0) + return ret; + if (ret == 0) + return -ETIMEDOUT; + return 0; } EXPORT_SYMBOL(ib_umem_dmabuf_map_pages); base-commit: 568035b01cfb107af8d2e4bd2fb9aea22cf5b868 -- 2.37.2

2 years, 9 months

3
2
0 0

[PATCH 0/5] Add dma-buf secure-heap

by Olivier Masse

Purpose of these patches is to add a new dma-buf heap: linaro,secure-heap Linaro OPTEE OS Secure Data Path feature is relying on a reserved memory defined at Linux Kernel level and OPTEE OS level. From Linux Kernel side, heap management is using dma-buf heaps interface. John Stultz (2): ANDROID: dma-buf: heaps: Add deferred-free-helper library code ANDROID: dma-buf: heaps: Add a shrinker controlled page pool Olivier Masse (3): dma-buf: heaps: add Linaro secure dmabuf heap support dt-bindings: reserved-memory: add linaro,secure-heap plat-hikey: Add linaro,secure-heap compatible .../reserved-memory/linaro,secure-heap.yaml | 56 ++ .../arm64/boot/dts/hisilicon/hi6220-hikey.dts | 11 + arch/arm64/configs/defconfig | 4 + drivers/dma-buf/heaps/Kconfig | 19 + drivers/dma-buf/heaps/Makefile | 3 + drivers/dma-buf/heaps/deferred-free-helper.c | 136 ++++ drivers/dma-buf/heaps/deferred-free-helper.h | 63 ++ drivers/dma-buf/heaps/page_pool.c | 246 ++++++++ drivers/dma-buf/heaps/page_pool.h | 55 ++ drivers/dma-buf/heaps/secure_heap.c | 588 ++++++++++++++++++ 10 files changed, 1181 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h create mode 100644 drivers/dma-buf/heaps/page_pool.c create mode 100644 drivers/dma-buf/heaps/page_pool.h create mode 100644 drivers/dma-buf/heaps/secure_heap.c -- 2.25.0

2 years, 9 months

3
12
0 0

[PATCH] drm/ast: add dmabuf/prime buffer sharing support

by oushixiong

This patch adds ast specific codes for DRM prime feature. Add the prime function to solve the xorg conflict problem when AST and AMD are in place at the same time, so that both can be displayed. Signed-off-by: oushixiong <oushixiong(a)kylinos.cn> Reported-by: kernel test robot <lkp(a)intel.com> --- drivers/gpu/drm/ast/ast_drv.c | 22 ++++++ drivers/gpu/drm/ast/ast_mode.c | 125 ++++++++++++++++++++++++++++++++- 2 files changed, 146 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 7465c4f0156a..6c1f75174368 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast/ast_drv.c @@ -28,6 +28,7 @@ #include <linux/module.h> #include <linux/pci.h> +#include <linux/dma-buf.h> #include <drm/drm_aperture.h> #include <drm/drm_atomic_helper.h> @@ -50,6 +51,23 @@ module_param_named(modeset, ast_modeset, int, 0400); DEFINE_DRM_GEM_FOPS(ast_fops); +static struct drm_gem_object *ast_gem_prime_import_sg_table(struct drm_device *dev, + struct dma_buf_attachment *attach, + struct sg_table *sg) +{ + struct drm_gem_vram_object *gbo; + struct dma_resv *resv = attach->dmabuf->resv; + + ww_mutex_lock(&resv->lock, NULL); + gbo = drm_gem_vram_create(dev, attach->dmabuf->size, 0); + ww_mutex_unlock(&resv->lock); + + if (IS_ERR(gbo)) + return NULL; + + return &gbo->bo.base; +} + static const struct drm_driver ast_driver = { .driver_features = DRIVER_ATOMIC | DRIVER_GEM | @@ -63,6 +81,10 @@ static const struct drm_driver ast_driver = { .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, + .prime_fd_to_handle = drm_gem_prime_fd_to_handle, + .gem_prime_import_sg_table = ast_gem_prime_import_sg_table, + DRM_GEM_VRAM_DRIVER }; diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 45b56b39ad47..ebe732705e34 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -48,6 +48,8 @@ #include "ast_drv.h" #include "ast_tables.h" +MODULE_IMPORT_NS(DMA_BUF); + static inline void ast_load_palette_index(struct ast_private *ast, u8 index, u8 red, u8 green, u8 blue) @@ -1535,8 +1537,129 @@ static const struct drm_mode_config_helper_funcs ast_mode_config_helper_funcs = .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm, }; +static int ast_handle_damage(struct drm_framebuffer *fb, int x, int y, + int width, int height) +{ + struct drm_gem_vram_object *dst_bo = NULL; + void *dst = NULL; + int ret = 0, i; + unsigned long offset = 0; + bool unmap = false; + unsigned int bytesPerPixel; + struct iosys_map map; + struct iosys_map dmabuf_map; + + bytesPerPixel = fb->format->cpp[0]; + + if (!fb->obj[0]->import_attach) + return -EINVAL; + + if (!fb->obj[0]->import_attach->dmabuf->vmap_ptr.vaddr) { + ret = dma_buf_vmap(fb->obj[0]->import_attach->dmabuf, &dmabuf_map); + if (ret) + return 0; + } else + dmabuf_map.vaddr = fb->obj[0]->import_attach->dmabuf->vmap_ptr.vaddr; + + dst_bo = drm_gem_vram_of_gem(fb->obj[0]); + + ret = drm_gem_vram_pin(dst_bo, 0); + if (ret) { + DRM_ERROR("ast_bo_pin failed\n"); + goto error; + } + + if (!dst_bo->map.vaddr) { + ret = drm_gem_vram_vmap(dst_bo, &map); + if (ret) { + DRM_ERROR("failed to vmap fbcon\n"); + drm_gem_vram_unpin(dst_bo); + goto error; + } + unmap = true; + } + dst = dst_bo->map.vaddr; + + for (i = y; i < y + height; i++) { + offset = i * fb->pitches[0] + (x * bytesPerPixel); + memcpy_toio(dst + offset, dmabuf_map.vaddr + offset, + width * bytesPerPixel); + } + + if (unmap) + drm_gem_vram_vunmap(dst_bo, &map); + + drm_gem_vram_unpin(dst_bo); +error: + return 0; +} + + +static int ast_user_framebuffer_dirty(struct drm_framebuffer *fb, + struct drm_file *file, + unsigned int flags, + unsigned int color, + struct drm_clip_rect *clips, + unsigned int num_clips) +{ + int i, ret = 0; + + drm_modeset_lock_all(fb->dev); + if (fb->obj[0]->import_attach) { + ret = dma_buf_begin_cpu_access(fb->obj[0]->import_attach->dmabuf, + DMA_FROM_DEVICE); + if (ret) + goto unlock; + } + + for (i = 0; i < num_clips; i++) { + ret = ast_handle_damage(fb, clips[i].x1, clips[i].y1, + clips[i].x2 - clips[i].x1, clips[i].y2 - clips[i].y1); + if (ret) + break; + } + + if (fb->obj[0]->import_attach) { + dma_buf_end_cpu_access(fb->obj[0]->import_attach->dmabuf, + DMA_FROM_DEVICE); + } + +unlock: + drm_modeset_unlock_all(fb->dev); + + return ret; +} + +static void ast_user_framebuffer_destroy(struct drm_framebuffer *fb) +{ + struct iosys_map dmabuf_map; + + if (fb->obj[0]->import_attach) { + dmabuf_map.vaddr = fb->obj[0]->import_attach->dmabuf->vmap_ptr.vaddr; + if (dmabuf_map.vaddr) + dma_buf_vunmap(fb->obj[0]->import_attach->dmabuf, + &dmabuf_map); + } + + drm_gem_fb_destroy(fb); +} + +static const struct drm_framebuffer_funcs ast_gem_fb_funcs_dirtyfb = { + .destroy = ast_user_framebuffer_destroy, + .create_handle = drm_gem_fb_create_handle, + .dirty = ast_user_framebuffer_dirty, +}; + +static struct drm_framebuffer * +ast_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file, + const struct drm_mode_fb_cmd2 *mode_cmd) +{ + return drm_gem_fb_create_with_funcs(dev, file, mode_cmd, + &ast_gem_fb_funcs_dirtyfb); +} + static const struct drm_mode_config_funcs ast_mode_config_funcs = { - .fb_create = drm_gem_fb_create, + .fb_create = ast_gem_fb_create_with_dirty, .mode_valid = drm_vram_helper_mode_valid, .atomic_check = drm_atomic_helper_check, .atomic_commit = drm_atomic_helper_commit, -- 2.17.1 No virus found Checked by Hillstone Network AntiVirus

2 years, 9 months

1
0
0 0

Attention: your linaro-mm-sig@lists.linaro.org Account storage is almost full

by Noreply＠lists.linaro.org

2 years, 9 months

1
0
0 0

[PATCH] drm/amd/amdgpu: Replace kmap() with kmap_local_page()

by Fabio M. De Francesco

kmap() is being deprecated in favor of kmap_local_page(). There are two main problems with kmap(): (1) It comes with an overhead as mapping space is restricted and protected by a global lock for synchronization and (2) it also requires global TLB invalidation when the kmap’s pool wraps and it might block when the mapping space is fully utilized until a slot becomes available. With kmap_local_page() the mappings are per thread, CPU local, can take page faults, and can be called from any context (including interrupts). It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored and are still valid. Since its use in amdgpu/amdgpu_ttm.c is safe, it should be preferred. Therefore, replace kmap() with kmap_local_page() in amdgpu/amdgpu_ttm.c. Suggested-by: Ira Weiny <ira.weiny(a)intel.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco(a)gmail.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 3b4c19412625..c11657b5915f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -2301,9 +2301,9 @@ static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf, if (p->mapping != adev->mman.bdev.dev_mapping) return -EPERM; - ptr = kmap(p); + ptr = kmap_local_page(p); r = copy_to_user(buf, ptr + off, bytes); - kunmap(p); + kunmap_local(ptr); if (r) return -EFAULT; @@ -2352,9 +2352,9 @@ static ssize_t amdgpu_iomem_write(struct file *f, const char __user *buf, if (p->mapping != adev->mman.bdev.dev_mapping) return -EPERM; - ptr = kmap(p); + ptr = kmap_local_page(p); r = copy_from_user(ptr + off, buf, bytes); - kunmap(p); + kunmap_local(ptr); if (r) return -EFAULT; -- 2.37.1

2 years, 9 months

2
1
0 0

Re: [EXT] Re: [PATCH 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor

by olivier.masse＠nxp.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 years, 9 months

1
0
0 0

[PATCH 0/1] tee: Add tee_shm_register_fd

by Olivier Masse

Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a shared memory from a dmabuf file descriptor. Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor drivers/tee/tee_core.c | 38 +++++++++++++++ drivers/tee/tee_shm.c | 99 +++++++++++++++++++++++++++++++++++++++- include/linux/tee_drv.h | 11 +++++ include/uapi/linux/tee.h | 29 ++++++++++++ 4 files changed, 175 insertions(+), 2 deletions(-) -- 2.25.0

2 years, 9 months

4
6
0 0

[PATCH v2 0/5] Move all drivers to a common dma-buf locking convention

by Dmitry Osipenko

Hello, This series moves all drivers to a dynamic dma-buf locking specification. From now on all dma-buf importers are made responsible for holding dma-buf's reservation lock around all operations performed over dma-bufs in accordance to the locking specification. This allows us to utilize reservation lock more broadly around kernel without fearing of a potential deadlocks. This patchset passes all i915 selftests. It was also tested using VirtIO, Panfrost, Lima and Tegra drivers. I tested cases of display+GPU, display+V4L and GPU+V4L dma-buf sharing, which covers majority of kernel drivers since rest of the drivers share same or similar code paths. Changelog: v2: - Changed locking specification to avoid problems with a cross-driver ww locking, like was suggested by Christian König. Now the attach/detach callbacks are invoked without the held lock and exporter should take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (5): dma-buf: Add _unlocked postfix to function names drm/gem: Take reservation lock for vmap/vunmap operations dma-buf: Move all dma-bufs to dynamic locking specification media: videobuf2: Stop using internal dma-buf lock dma-buf: Remove internal lock Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c | 253 +++++++++++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +- drivers/gpu/drm/armada/armada_gem.c | 14 +- drivers/gpu/drm/drm_client.c | 4 +- drivers/gpu/drm/drm_gem.c | 24 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 6 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 6 +- drivers/gpu/drm/drm_prime.c | 12 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 14 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 20 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 +- drivers/gpu/drm/qxl/qxl_object.c | 17 +- drivers/gpu/drm/qxl/qxl_prime.c | 4 +- drivers/gpu/drm/tegra/gem.c | 27 +- drivers/infiniband/core/umem_dmabuf.c | 11 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 23 +- .../common/videobuf2/videobuf2-vmalloc.c | 17 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 12 +- drivers/misc/fastrpc.c | 12 +- drivers/xen/gntdev-dmabuf.c | 14 +- include/drm/drm_gem.h | 3 + include/linux/dma-buf.h | 71 ++--- 28 files changed, 372 insertions(+), 254 deletions(-) -- 2.36.1

2 years, 9 months

3
14
0 0

[PATCH AUTOSEL 5.4 09/25] udmabuf: Set the DMA mask for the udmabuf device (v2)

by Sasha Levin

From: Vivek Kasireddy <vivek.kasireddy(a)intel.com> [ Upstream commit 9e9fa6a9198b767b00f48160800128e83a038f9f ] If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2(a)syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek… Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c6e9b7bd7618..80ccdf96093f 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -287,7 +287,23 @@ static struct miscdevice udmabuf_misc = { static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret = misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } static void __exit udmabuf_dev_exit(void) -- 2.35.1

2 years, 10 months

1
0
0 0

[PATCH AUTOSEL 5.10 12/46] udmabuf: Set the DMA mask for the udmabuf device (v2)

by Sasha Levin

From: Vivek Kasireddy <vivek.kasireddy(a)intel.com> [ Upstream commit 9e9fa6a9198b767b00f48160800128e83a038f9f ] If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2(a)syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek… Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 2e3b76519b49..b624f3d8f0e6 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -327,7 +327,23 @@ static struct miscdevice udmabuf_misc = { static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret = misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } static void __exit udmabuf_dev_exit(void) -- 2.35.1

2 years, 10 months

1
0
0 0

[PATCH AUTOSEL 5.15 18/69] udmabuf: Set the DMA mask for the udmabuf device (v2)

by Sasha Levin

From: Vivek Kasireddy <vivek.kasireddy(a)intel.com> [ Upstream commit 9e9fa6a9198b767b00f48160800128e83a038f9f ] If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2(a)syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek… Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 9631f2fd2faf..38e8767ec371 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -368,7 +368,23 @@ static struct miscdevice udmabuf_misc = { static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret = misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } static void __exit udmabuf_dev_exit(void) -- 2.35.1

2 years, 10 months

1
0
0 0

[PATCH AUTOSEL 5.18 20/93] udmabuf: Set the DMA mask for the udmabuf device (v2)

by Sasha Levin

From: Vivek Kasireddy <vivek.kasireddy(a)intel.com> [ Upstream commit 9e9fa6a9198b767b00f48160800128e83a038f9f ] If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2(a)syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek… Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 9631f2fd2faf..38e8767ec371 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -368,7 +368,23 @@ static struct miscdevice udmabuf_misc = { static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret = misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } static void __exit udmabuf_dev_exit(void) -- 2.35.1

2 years, 10 months

1
0
0 0

[PATCH AUTOSEL 5.19 021/105] udmabuf: Set the DMA mask for the udmabuf device (v2)

by Sasha Levin

From: Vivek Kasireddy <vivek.kasireddy(a)intel.com> [ Upstream commit 9e9fa6a9198b767b00f48160800128e83a038f9f ] If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2(a)syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek… Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 9631f2fd2faf..38e8767ec371 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -368,7 +368,23 @@ static struct miscdevice udmabuf_misc = { static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret = misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } static void __exit udmabuf_dev_exit(void) -- 2.35.1

2 years, 10 months

1
0
0 0

[PATCH] i2c: qcom-geni: Fix GPI DMA buffer sync-back

by Robin Reckmann

Fix i2c transfers using GPI DMA mode for all message types that do not set the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte"). In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(), and it has to synced back to the message after the transfer is done. Add missing assignment of dma buffer in geni_i2c_gpi(). Set xferred in i2c_put_dma_safe_msg_buf() to true in case of no error to ensure the sync-back of this dma buffer to the message. Signed-off-by: Robin Reckmann <robin.reckmann(a)gmail.com> --- drivers/i2c/busses/i2c-qcom-geni.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c index 6ac402ea58fb..d3541e94794e 100644 --- a/drivers/i2c/busses/i2c-qcom-geni.c +++ b/drivers/i2c/busses/i2c-qcom-geni.c @@ -484,12 +484,12 @@ static void geni_i2c_gpi_unmap(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, { if (tx_buf) { dma_unmap_single(gi2c->se.dev->parent, tx_addr, msg->len, DMA_TO_DEVICE); - i2c_put_dma_safe_msg_buf(tx_buf, msg, false); + i2c_put_dma_safe_msg_buf(tx_buf, msg, !gi2c->err); } if (rx_buf) { dma_unmap_single(gi2c->se.dev->parent, rx_addr, msg->len, DMA_FROM_DEVICE); - i2c_put_dma_safe_msg_buf(rx_buf, msg, false); + i2c_put_dma_safe_msg_buf(rx_buf, msg, !gi2c->err); } } @@ -553,6 +553,7 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg *msg, desc->callback_param = gi2c; dmaengine_submit(desc); + *buf = dma_buf; *dma_addr_p = addr; return 0; -- 2.25.1

2 years, 10 months

5
6
0 0

[PATCH] dma-buf: revert "return only unsignaled fences in dma_fence_unwrap_for_each v3"

by Christian König

This reverts commit 8f61973718485f3e89bc4f408f929048b7b47c83. It turned out that this is not correct. Especially the sync_file info IOCTL needs to see even signaled fences to correctly report back their status to userspace. Instead add the filter in the merge function again where it makes sense. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence-unwrap.c | 3 ++- include/linux/dma-fence-unwrap.h | 6 +----- 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-fence-unwrap.c b/drivers/dma-buf/dma-fence-unwrap.c index 502a65ea6d44..7002bca792ff 100644 --- a/drivers/dma-buf/dma-fence-unwrap.c +++ b/drivers/dma-buf/dma-fence-unwrap.c @@ -72,7 +72,8 @@ struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, count = 0; for (i = 0; i < num_fences; ++i) { dma_fence_unwrap_for_each(tmp, &iter[i], fences[i]) - ++count; + if (!dma_fence_is_signaled(tmp)) + ++count; } if (count == 0) diff --git a/include/linux/dma-fence-unwrap.h b/include/linux/dma-fence-unwrap.h index 390de1ee9d35..66b1e56fbb81 100644 --- a/include/linux/dma-fence-unwrap.h +++ b/include/linux/dma-fence-unwrap.h @@ -43,14 +43,10 @@ struct dma_fence *dma_fence_unwrap_next(struct dma_fence_unwrap *cursor); * Unwrap dma_fence_chain and dma_fence_array containers and deep dive into all * potential fences in them. If @head is just a normal fence only that one is * returned. - * - * Note that signalled fences are opportunistically filtered out, which - * means the iteration is potentially over no fence at all. */ #define dma_fence_unwrap_for_each(fence, cursor, head) \ for (fence = dma_fence_unwrap_first(head, cursor); fence; \ - fence = dma_fence_unwrap_next(cursor)) \ - if (!dma_fence_is_signaled(fence)) + fence = dma_fence_unwrap_next(cursor)) struct dma_fence *__dma_fence_unwrap_merge(unsigned int num_fences, struct dma_fence **fences, -- 2.25.1

2 years, 10 months

6
11
0 0

[PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

by Christian König

Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit synced user space submissions as well and document the rules around adding the same fence with different usages. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- include/linux/dma-resv.h | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index c8ccbc94d5d2..264e27e56dff 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -62,6 +62,11 @@ struct dma_resv_list; * For example when asking for WRITE fences then the KERNEL fences are returned * as well. Similar when asked for READ fences then both WRITE and KERNEL * fences are returned as well. + * + * Already used fences can be promoted in the sense that a fence with + * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding it again + * with this usage. But fences can never be degraded in the sense that a fence + * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ. */ enum dma_resv_usage { /** @@ -98,10 +103,15 @@ enum dma_resv_usage { * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync. * * This should be used by submissions which don't want to participate in - * implicit synchronization. + * any implicit synchronization. + * + * The most common case are preemption fences, page table updates, TLB + * flushes as well as explicit synced user submissions. * - * The most common case are preemption fences as well as page table - * updates and their TLB flushes. + * Explicit synced user user submissions can be promoted to + * DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using + * dma_buf_import_sync_file() when implicit synchronization should + * become necessary after initial adding of the fence. */ DMA_RESV_USAGE_BOOKKEEP }; -- 2.25.1

2 years, 10 months

5
4
0 0

[PATCH] dma-buf/sync_file: use strscpy to replace strlcpy

by XueBing Chen

The strlcpy should not be used because it doesn't limit the source length. Preferred is strscpy. Signed-off-by: XueBing Chen <chenxuebing(a)jari.cn> --- drivers/dma-buf/sync_file.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index 3ebec19a8e02..af57799c86ce 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -132,7 +132,7 @@ EXPORT_SYMBOL(sync_file_get_fence); char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len) { if (sync_file->user_name[0]) { - strlcpy(buf, sync_file->user_name, len); + strscpy(buf, sync_file->user_name, len); } else { struct dma_fence *fence = sync_file->fence; @@ -172,7 +172,7 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, return NULL; } sync_file->fence = fence; - strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name)); + strscpy(sync_file->user_name, name, sizeof(sync_file->user_name)); return sync_file; } @@ -262,9 +262,9 @@ static long sync_file_ioctl_merge(struct sync_file *sync_file, static int sync_fill_fence_info(struct dma_fence *fence, struct sync_fence_info *info) { - strlcpy(info->obj_name, fence->ops->get_timeline_name(fence), + strscpy(info->obj_name, fence->ops->get_timeline_name(fence), sizeof(info->obj_name)); - strlcpy(info->driver_name, fence->ops->get_driver_name(fence), + strscpy(info->driver_name, fence->ops->get_driver_name(fence), sizeof(info->driver_name)); info->status = dma_fence_get_status(fence); -- 2.25.1

2 years, 10 months

2
1
0 0

[PATCH v2] drm/gem: Fix GEM handle release errors

by Jeffy Chen

Currently we are assuming a one to one mapping between dmabuf and handle when releasing GEM handles. But that is not always true, since we would create extra handles for the GEM obj in cases like gem_open() and getfb{,2}(). A similar issue was reported at: https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/ Another problem is that the drm_gem_remove_prime_handles() now only remove handle to the exported dmabuf (gem_obj->dma_buf), so the imported ones would leak: WARNING: CPU: 2 PID: 236 at drivers/gpu/drm/drm_prime.c:228 drm_prime_destroy_file_private+0x18/0x24 Let's fix these by using handle to find the exact map to remove. Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com> --- Changes in v2: Fix a typo of rbtree. drivers/gpu/drm/drm_gem.c | 17 +---------------- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 20 ++++++++++++-------- 3 files changed, 15 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index eb0c2d041f13..ed39da383570 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -168,21 +168,6 @@ void drm_gem_private_object_init(struct drm_device *dev, } EXPORT_SYMBOL(drm_gem_private_object_init); -static void -drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp) -{ - /* - * Note: obj->dma_buf can't disappear as long as we still hold a - * handle reference in obj->handle_count. - */ - mutex_lock(&filp->prime.lock); - if (obj->dma_buf) { - drm_prime_remove_buf_handle_locked(&filp->prime, - obj->dma_buf); - } - mutex_unlock(&filp->prime.lock); -} - /** * drm_gem_object_handle_free - release resources bound to userspace handles * @obj: GEM object to clean up. @@ -253,7 +238,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) if (obj->funcs->close) obj->funcs->close(obj, file_priv); - drm_gem_remove_prime_handles(obj, file_priv); + drm_prime_remove_buf_handle(&file_priv->prime, id); drm_vma_node_revoke(&obj->vma_node, file_priv); drm_gem_object_handle_put_unlocked(obj); diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 1fbbc19f1ac0..7bb98e6a446d 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -74,8 +74,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data, void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv); void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv); -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf); +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle); /* drm_drv.c */ struct drm_minor *drm_minor_acquire(unsigned int minor_id); diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index e3f09f18110c..bd5366b16381 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -190,29 +190,33 @@ static int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpri return -ENOENT; } -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf) +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle) { struct rb_node *rb; - rb = prime_fpriv->dmabufs.rb_node; + mutex_lock(&prime_fpriv->lock); + + rb = prime_fpriv->handles.rb_node; while (rb) { struct drm_prime_member *member; - member = rb_entry(rb, struct drm_prime_member, dmabuf_rb); - if (member->dma_buf == dma_buf) { + member = rb_entry(rb, struct drm_prime_member, handle_rb); + if (member->handle == handle) { rb_erase(&member->handle_rb, &prime_fpriv->handles); rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs); - dma_buf_put(dma_buf); + dma_buf_put(member->dma_buf); kfree(member); - return; - } else if (member->dma_buf < dma_buf) { + break; + } else if (member->handle < handle) { rb = rb->rb_right; } else { rb = rb->rb_left; } } + + mutex_unlock(&prime_fpriv->lock); } void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv) -- 2.20.1

2 years, 10 months

3
11
0 0

DMA-buf and uncached system memory

by Christian König

Hi guys, we are currently working an Freesync and direct scan out from system memory on AMD APUs in A+A laptops. On problem we stumbled over is that our display hardware needs to scan out from uncached system memory and we currently don't have a way to communicate that through DMA-buf. For our specific use case at hand we are going to implement something driver specific, but the question is should we have something more generic for this? After all the system memory access pattern is a PCIe extension and as such something generic. Regards, Christian.

2 years, 10 months

9
35
0 0

[PATCH 0/1] [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats

by Dennis Tsiang

This patch is an early RFC to discuss the viable options and alternatives for inclusion of unsigned integer formats for the DRM API. This patch adds a new single component 16-bit and a two component 32-bit DRM fourcc’s that represent unsigned integer formats. The use case for needing UINT formats, in our case, would be to support using raw buffers for camera ISPs. For images imported with DRM fourcc + modifier combination, the GPU driver needs a way to determine the datatype of the format which currently the DRM API does not provide explicitly with a notable exception of the floating-point fourccs such as DRM_FORMAT_XRGB16161616F as an example. As the DRM fourccs do not currently define the interpretation of the data, should the information be made explicit in the DRM API similarly to how it is already done in Vulkan? The reason for introducing datatype to the DRM fourcc's is that the alternative, for any API (e.g., EGL) that lacks the format datatype information for fourcc/modifier combination for dma_buf interop would be to introduce explicit additional metadata/attributes that encode this information which then would be passed to the GPU driver but the drawback of this is that it would require extending multiple graphics APIs to support every single platform. By having the DRM API expose the datatype information for formats saves a lot of integration/verification work for all of the different graphics APIs and platforms as this information could be determined by the DRM triple alone for dma_buf interop. It would be good to gather some opinions on what others think about introducing datatypes to the DRM API. Any feedback and suggestions are highly appreciated. Dennis Tsiang (1): [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats include/uapi/drm/drm_fourcc.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.36.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.

2 years, 10 months

5
7
0 0

[PATCH] drm/gem: Fix GEM handle release errors

by Jeffy Chen

Currently we are assuming a one to one mapping between dmabuf and handle when releasing GEM handles. But that is not always true, since we would create extra handles for the GEM obj in cases like gem_open() and getfb{,2}(). A similar issue was reported at: https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/ Another problem is that the drm_gem_remove_prime_handles() now only remove handle to the exported dmabuf (gem_obj->dma_buf), so the imported ones would leak: WARNING: CPU: 2 PID: 236 at drivers/gpu/drm/drm_prime.c:228 drm_prime_destroy_file_private+0x18/0x24 Let's fix these by using handle to find the exact map to remove. Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com> --- drivers/gpu/drm/drm_gem.c | 17 +---------------- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 16 ++++++++++------ 3 files changed, 13 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index eb0c2d041f13..ed39da383570 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -168,21 +168,6 @@ void drm_gem_private_object_init(struct drm_device *dev, } EXPORT_SYMBOL(drm_gem_private_object_init); -static void -drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp) -{ - /* - * Note: obj->dma_buf can't disappear as long as we still hold a - * handle reference in obj->handle_count. - */ - mutex_lock(&filp->prime.lock); - if (obj->dma_buf) { - drm_prime_remove_buf_handle_locked(&filp->prime, - obj->dma_buf); - } - mutex_unlock(&filp->prime.lock); -} - /** * drm_gem_object_handle_free - release resources bound to userspace handles * @obj: GEM object to clean up. @@ -253,7 +238,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) if (obj->funcs->close) obj->funcs->close(obj, file_priv); - drm_gem_remove_prime_handles(obj, file_priv); + drm_prime_remove_buf_handle(&file_priv->prime, id); drm_vma_node_revoke(&obj->vma_node, file_priv); drm_gem_object_handle_put_unlocked(obj); diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 1fbbc19f1ac0..7bb98e6a446d 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -74,8 +74,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data, void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv); void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv); -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf); +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle); /* drm_drv.c */ struct drm_minor *drm_minor_acquire(unsigned int minor_id); diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index e3f09f18110c..c28518ab62d0 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -190,29 +190,33 @@ static int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpri return -ENOENT; } -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf) +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle) { struct rb_node *rb; + mutex_lock(&prime_fpriv->lock); + rb = prime_fpriv->dmabufs.rb_node; while (rb) { struct drm_prime_member *member; member = rb_entry(rb, struct drm_prime_member, dmabuf_rb); - if (member->dma_buf == dma_buf) { + if (member->handle == handle) { rb_erase(&member->handle_rb, &prime_fpriv->handles); rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs); - dma_buf_put(dma_buf); + dma_buf_put(member->dma_buf); kfree(member); - return; - } else if (member->dma_buf < dma_buf) { + break; + } else if (member->handle < handle) { rb = rb->rb_right; } else { rb = rb->rb_left; } } + + mutex_unlock(&prime_fpriv->lock); } void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv) -- 2.20.1

2 years, 10 months

3
2
0 0

[PATCH RFC] dma-buf: To check DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT status on debug

by Arvind Yadav

If core DMA-buf framework forgets to call dma_fence_enable_signaling() before calling the dma_fence_is_signaled(). To handle this scenario on debug kernel the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT needs to be checked before checking the actual signaling status. Signed-off-by: Arvind Yadav <Arvind.Yadav(a)amd.com> --- include/linux/dma-fence.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 775cdc0b4f24..7c95c8d5e5f5 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -428,6 +428,10 @@ dma_fence_is_signaled_locked(struct dma_fence *fence) static inline bool dma_fence_is_signaled(struct dma_fence *fence) { +#ifdef CONFIG_DEBUG_FS + if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags)) + return true; +#endif if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) return true; -- 2.25.1

2 years, 10 months

2
1
0 0

[PATCH 0/3] dma-buf: map-info support

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> See 1/3 for motivation. Rob Clark (3): dma-buf: Add ioctl to query mmap info drm/prime: Wire up mmap_info support drm/msm/prime: Add mmap_info support drivers/dma-buf/dma-buf.c | 26 ++++++++++++++++++++++++++ drivers/gpu/drm/drm_prime.c | 12 ++++++++++++ drivers/gpu/drm/msm/msm_drv.c | 1 + drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gem_prime.c | 11 +++++++++++ include/drm/drm_drv.h | 7 +++++++ include/linux/dma-buf.h | 7 +++++++ include/uapi/linux/dma-buf.h | 28 ++++++++++++++++++++++++++++ 8 files changed, 93 insertions(+) -- 2.36.1

2 years, 10 months

5
16
0 0

[PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support

by Olivier Masse

add Linaro secure heap compatible reserved mem: linaro,secure-heap use genalloc to allocate/free buffer from buffer pool. buffer pool info is defined from a dts reserved memory. Signed-off-by: Olivier Masse <olivier.masse(a)nxp.com> --- drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/secure_heap.c | 339 ++++++++++++++++++++++++++++ 3 files changed, 349 insertions(+) create mode 100644 drivers/dma-buf/heaps/secure_heap.c diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index 3782eeeb91c0..c9070c728b9a 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -20,3 +20,12 @@ config DMABUF_HEAPS_DSP Choose this option to enable the dsp dmabuf heap. The dsp heap is allocated by gen allocater. it's allocated according the dts. If in doubt, say Y. + +config DMABUF_HEAPS_SECURE + tristate "DMA-BUF Secure Heap" + depends on DMABUF_HEAPS + help + Choose this option to enable the secure dmabuf heap. The secure heap + pools are defined according to the DT. Heaps are allocated + in the pools using gen allocater. + If in doubt, say Y. diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile index 29733f84c354..863ef10056a3 100644 --- a/drivers/dma-buf/heaps/Makefile +++ b/drivers/dma-buf/heaps/Makefile @@ -2,3 +2,4 @@ obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o obj-$(CONFIG_DMABUF_HEAPS_DSP) += dsp_heap.o +obj-$(CONFIG_DMABUF_HEAPS_SECURE) += secure_heap.o diff --git a/drivers/dma-buf/heaps/secure_heap.c b/drivers/dma-buf/heaps/secure_heap.c new file mode 100644 index 000000000000..a3023bf8d457 --- /dev/null +++ b/drivers/dma-buf/heaps/secure_heap.c @@ -0,0 +1,339 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * DMABUF secure heap exporter + * + * Copyright 2022 NXP. + */ + +#include <linux/dma-buf.h> +#include <linux/dma-heap.h> +#include <linux/dma-mapping.h> +#include <linux/err.h> +#include <linux/genalloc.h> +#include <linux/highmem.h> +#include <linux/mm.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/of_fdt.h> +#include <linux/of_reserved_mem.h> +#include <linux/scatterlist.h> +#include <linux/slab.h> +#include <linux/vmalloc.h> + +#define MAX_SECURE_HEAP 2 +#define MAX_HEAP_NAME_LEN 32 + +struct secure_heap_buffer { + struct dma_heap *heap; + struct list_head attachments; + struct mutex lock; + unsigned long len; + struct sg_table sg_table; + int vmap_cnt; + void *vaddr; +}; + +struct secure_heap_attachment { + struct device *dev; + struct sg_table *table; + struct list_head list; +}; + +struct secure_heap_info { + struct gen_pool *pool; +}; + +struct rmem_secure { + phys_addr_t base; + phys_addr_t size; + + char name[MAX_HEAP_NAME_LEN]; +}; + +static struct rmem_secure secure_data[MAX_SECURE_HEAP] = {0}; +static unsigned int secure_data_count; + +static struct sg_table *dup_sg_table(struct sg_table *table) +{ + struct sg_table *new_table; + int ret, i; + struct scatterlist *sg, *new_sg; + + new_table = kzalloc(sizeof(*new_table), GFP_KERNEL); + if (!new_table) + return ERR_PTR(-ENOMEM); + + ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL); + if (ret) { + kfree(new_table); + return ERR_PTR(-ENOMEM); + } + + new_sg = new_table->sgl; + for_each_sgtable_sg(table, sg, i) { + sg_set_page(new_sg, sg_page(sg), sg->length, sg->offset); + new_sg->dma_address = sg->dma_address; +#ifdef CONFIG_NEED_SG_DMA_LENGTH + new_sg->dma_length = sg->dma_length; +#endif + new_sg = sg_next(new_sg); + } + + return new_table; +} + +static int secure_heap_attach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct secure_heap_buffer *buffer = dmabuf->priv; + struct secure_heap_attachment *a; + struct sg_table *table; + + a = kzalloc(sizeof(*a), GFP_KERNEL); + if (!a) + return -ENOMEM; + + table = dup_sg_table(&buffer->sg_table); + if (IS_ERR(table)) { + kfree(a); + return PTR_ERR(table); + } + + a->table = table; + a->dev = attachment->dev; + INIT_LIST_HEAD(&a->list); + attachment->priv = a; + + mutex_lock(&buffer->lock); + list_add(&a->list, &buffer->attachments); + mutex_unlock(&buffer->lock); + + return 0; +} + +static void secure_heap_detach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct secure_heap_buffer *buffer = dmabuf->priv; + struct secure_heap_attachment *a = attachment->priv; + + mutex_lock(&buffer->lock); + list_del(&a->list); + mutex_unlock(&buffer->lock); + + sg_free_table(a->table); + kfree(a->table); + kfree(a); +} + +static struct sg_table *secure_heap_map_dma_buf(struct dma_buf_attachment *attachment, + enum dma_data_direction direction) +{ + struct secure_heap_attachment *a = attachment->priv; + + return a->table; +} + +static void secure_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, + struct sg_table *table, + enum dma_data_direction direction) +{ +} + +static void secure_heap_dma_buf_release(struct dma_buf *dmabuf) +{ + struct secure_heap_buffer *buffer = dmabuf->priv; + struct secure_heap_info *info; + struct sg_table *table; + struct scatterlist *sg; + int i; + + info = dma_heap_get_drvdata(buffer->heap); + + table = &buffer->sg_table; + for_each_sg(table->sgl, sg, table->nents, i) + gen_pool_free(info->pool, sg_dma_address(sg), sg_dma_len(sg)); + + sg_free_table(table); + kfree(buffer); +} + +static const struct dma_buf_ops secure_heap_buf_ops = { + .attach = secure_heap_attach, + .detach = secure_heap_detach, + .map_dma_buf = secure_heap_map_dma_buf, + .unmap_dma_buf = secure_heap_unmap_dma_buf, + .release = secure_heap_dma_buf_release, +}; + +static struct dma_buf *secure_heap_allocate(struct dma_heap *heap, + unsigned long len, + unsigned long fd_flags, + unsigned long heap_flags) +{ + struct secure_heap_buffer *buffer; + struct secure_heap_info *info = dma_heap_get_drvdata(heap); + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); + unsigned long size = roundup(len, PAGE_SIZE); + struct dma_buf *dmabuf; + struct sg_table *table; + int ret = -ENOMEM; + unsigned long phy_addr; + + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL); + if (!buffer) + return ERR_PTR(-ENOMEM); + + INIT_LIST_HEAD(&buffer->attachments); + mutex_init(&buffer->lock); + buffer->heap = heap; + buffer->len = size; + + phy_addr = gen_pool_alloc(info->pool, size); + if (!phy_addr) + goto free_buffer; + + table = &buffer->sg_table; + if (sg_alloc_table(table, 1, GFP_KERNEL)) + goto free_pool; + + sg_set_page(table->sgl, phys_to_page(phy_addr), size, 0); + sg_dma_address(table->sgl) = phy_addr; + sg_dma_len(table->sgl) = size; + + /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); + exp_info.ops = &secure_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_table; + } + + return dmabuf; + +free_table: + sg_free_table(table); + +free_pool: + gen_pool_free(info->pool, phy_addr, size); + +free_buffer: + mutex_destroy(&buffer->lock); + kfree(buffer); + + return ERR_PTR(ret); +} + +static const struct dma_heap_ops secure_heap_ops = { + .allocate = secure_heap_allocate, +}; + +static int secure_heap_add(struct rmem_secure *rmem) +{ + struct dma_heap *secure_heap; + struct dma_heap_export_info exp_info; + struct secure_heap_info *info = NULL; + struct gen_pool *pool = NULL; + int ret = -EINVAL; + + if (rmem->base == 0 || rmem->size == 0) { + pr_err("secure_data base or size is not correct\n"); + goto error; + } + + info = kzalloc(sizeof(*info), GFP_KERNEL); + if (!info) { + pr_err("dmabuf info allocation failed\n"); + ret = -ENOMEM; + goto error; + } + + pool = gen_pool_create(PAGE_SHIFT, -1); + if (!pool) { + pr_err("can't create gen pool\n"); + ret = -ENOMEM; + goto error; + } + + if (gen_pool_add(pool, rmem->base, rmem->size, -1) < 0) { + pr_err("failed to add memory into pool\n"); + ret = -ENOMEM; + goto error; + } + + info->pool = pool; + + exp_info.name = rmem->name; + exp_info.ops = &secure_heap_ops; + exp_info.priv = info; + + secure_heap = dma_heap_add(&exp_info); + if (IS_ERR(secure_heap)) { + pr_err("dmabuf secure heap allocation failed\n"); + ret = PTR_ERR(secure_heap); + goto error; + } + + return 0; + +error: + if (pool) + gen_pool_destroy(pool); + kfree(info); + + return ret; +} + +static int secure_heap_create(void) +{ + unsigned int i; + int ret; + + for (i = 0; i < secure_data_count; i++) { + ret = secure_heap_add(&secure_data[i]); + if (ret) + return ret; + } + return 0; +} + +static int __init rmem_secure_heap_setup(struct reserved_mem *rmem) +{ + if (secure_data_count < MAX_SECURE_HEAP) { + int name_len = 0; + const char *s = rmem->name; + + secure_data[secure_data_count].base = rmem->base; + secure_data[secure_data_count].size = rmem->size; + + while (name_len < MAX_HEAP_NAME_LEN) { + if ((*s == '@') || (*s == '\0')) + break; + name_len++; + s++; + } + if (name_len == MAX_HEAP_NAME_LEN) + name_len--; + + strncpy(secure_data[secure_data_count].name, rmem->name, name_len); + secure_data[secure_data_count].name[name_len] = '\0'; + + pr_info("Reserved memory: DMA buf secure pool %s at %pa, size %ld MiB\n", + secure_data[secure_data_count].name, + &rmem->base, (unsigned long)rmem->size / SZ_1M); + + secure_data_count++; + return 0; + } + WARN_ONCE(1, "Cannot handle more than %u secure heaps\n", MAX_SECURE_HEAP); + return -EINVAL; +} + +RESERVEDMEM_OF_DECLARE(secure_heap, "linaro,secure-heap", rmem_secure_heap_setup); + +module_init(secure_heap_create); +MODULE_LICENSE("GPL v2"); -- 2.25.0

2 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig