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

[PATCH] dmabuf: fix NULL pointer dereference in dma_buf_release()

by Charan Teja Reddy

NULL pointer dereference is observed while exporting the dmabuf but failed to allocate the 'struct file' which results into the dropping of the allocated dentry corresponding to this file in the dmabuf fs, which is ending up in dma_buf_release() and accessing the uninitialzed dentry->d_fsdata. Call stack on 5.4 is below: dma_buf_release+0x2c/0x254 drivers/dma-buf/dma-buf.c:88 __dentry_kill+0x294/0x31c fs/dcache.c:584 dentry_kill fs/dcache.c:673 [inline] dput+0x250/0x380 fs/dcache.c:859 path_put+0x24/0x40 fs/namei.c:485 alloc_file_pseudo+0x1a4/0x200 fs/file_table.c:235 dma_buf_getfile drivers/dma-buf/dma-buf.c:473 [inline] dma_buf_export+0x25c/0x3ec drivers/dma-buf/dma-buf.c:585 Fix this by checking for the valid pointer in the dentry->d_fsdata. Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to dentry_ops") Cc: <stable(a)vger.kernel.org> [5.7+] Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org> --- drivers/dma-buf/dma-buf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 58564d82..844967f 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -59,6 +59,8 @@ static void dma_buf_release(struct dentry *dentry) struct dma_buf *dmabuf; dmabuf = dentry->d_fsdata; + if (unlikely(!dmabuf)) + return; BUG_ON(dmabuf->vmapping_counter); -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation

5 years, 4 months

3
2
0 0

[PATCH AUTOSEL 4.19 003/206] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling)

by Sasha Levin

From: Chris Wilson <chris(a)chris-wilson.co.uk> [ Upstream commit 9c98f021e4e717ffd9948fa65340ea3ef12b7935 ] Make dma_fence_enable_sw_signaling() behave like its dma_fence_add_callback() and dma_fence_default_wait() counterparts and perform the test to enable signaling under the fence->lock, along with the action to do so. This ensure that should an implementation be trying to flush the cb_list (by signaling) on retirement before freeing the fence, it can do so in a race-free manner. See also 0fc89b6802ba ("dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal"). v2: Refactor all 3 enable_signaling paths to use a common function. v3: Don't argue, just keep the tracepoint in the existing spot. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004101140.32713-1-chris@… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-fence.c | 78 +++++++++++++++++-------------------- 1 file changed, 35 insertions(+), 43 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 1551ca7df3941..8586cc05def17 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -244,6 +244,30 @@ void dma_fence_free(struct dma_fence *fence) } EXPORT_SYMBOL(dma_fence_free); +static bool __dma_fence_enable_signaling(struct dma_fence *fence) +{ + bool was_set; + + lockdep_assert_held(fence->lock); + + was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, + &fence->flags); + + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + return false; + + if (!was_set && fence->ops->enable_signaling) { + trace_dma_fence_enable_signal(fence); + + if (!fence->ops->enable_signaling(fence)) { + dma_fence_signal_locked(fence); + return false; + } + } + + return true; +} + /** * dma_fence_enable_sw_signaling - enable signaling on fence * @fence: the fence to enable @@ -256,19 +280,12 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence) { unsigned long flags; - if (!test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, - &fence->flags) && - !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) && - fence->ops->enable_signaling) { - trace_dma_fence_enable_signal(fence); - - spin_lock_irqsave(fence->lock, flags); - - if (!fence->ops->enable_signaling(fence)) - dma_fence_signal_locked(fence); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + return; - spin_unlock_irqrestore(fence->lock, flags); - } + spin_lock_irqsave(fence->lock, flags); + __dma_fence_enable_signaling(fence); + spin_unlock_irqrestore(fence->lock, flags); } EXPORT_SYMBOL(dma_fence_enable_sw_signaling); @@ -302,7 +319,6 @@ int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb, { unsigned long flags; int ret = 0; - bool was_set; if (WARN_ON(!fence || !func)) return -EINVAL; @@ -314,25 +330,14 @@ int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb, spin_lock_irqsave(fence->lock, flags); - was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, - &fence->flags); - - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) - ret = -ENOENT; - else if (!was_set && fence->ops->enable_signaling) { - trace_dma_fence_enable_signal(fence); - - if (!fence->ops->enable_signaling(fence)) { - dma_fence_signal_locked(fence); - ret = -ENOENT; - } - } - - if (!ret) { + if (__dma_fence_enable_signaling(fence)) { cb->func = func; list_add_tail(&cb->node, &fence->cb_list); - } else + } else { INIT_LIST_HEAD(&cb->node); + ret = -ENOENT; + } + spin_unlock_irqrestore(fence->lock, flags); return ret; @@ -432,7 +437,6 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout) struct default_wait_cb cb; unsigned long flags; signed long ret = timeout ? timeout : 1; - bool was_set; if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) return ret; @@ -444,21 +448,9 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout) goto out; } - was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, - &fence->flags); - - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + if (!__dma_fence_enable_signaling(fence)) goto out; - if (!was_set && fence->ops->enable_signaling) { - trace_dma_fence_enable_signal(fence); - - if (!fence->ops->enable_signaling(fence)) { - dma_fence_signal_locked(fence); - goto out; - } - } - if (!timeout) { ret = 0; goto out; -- 2.25.1

5 years, 4 months

1
0
0 0

[PATCH AUTOSEL 5.4 009/330] dma-fence: Serialise signal enabling (dma_fence_enable_sw_signaling)

by Sasha Levin

From: Chris Wilson <chris(a)chris-wilson.co.uk> [ Upstream commit 9c98f021e4e717ffd9948fa65340ea3ef12b7935 ] Make dma_fence_enable_sw_signaling() behave like its dma_fence_add_callback() and dma_fence_default_wait() counterparts and perform the test to enable signaling under the fence->lock, along with the action to do so. This ensure that should an implementation be trying to flush the cb_list (by signaling) on retirement before freeing the fence, it can do so in a race-free manner. See also 0fc89b6802ba ("dma-fence: Simply wrap dma_fence_signal_locked with dma_fence_signal"). v2: Refactor all 3 enable_signaling paths to use a common function. v3: Don't argue, just keep the tracepoint in the existing spot. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004101140.32713-1-chris@… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma-buf/dma-fence.c | 78 +++++++++++++++++-------------------- 1 file changed, 35 insertions(+), 43 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 2c136aee3e794..052a41e2451c1 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -273,6 +273,30 @@ void dma_fence_free(struct dma_fence *fence) } EXPORT_SYMBOL(dma_fence_free); +static bool __dma_fence_enable_signaling(struct dma_fence *fence) +{ + bool was_set; + + lockdep_assert_held(fence->lock); + + was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, + &fence->flags); + + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + return false; + + if (!was_set && fence->ops->enable_signaling) { + trace_dma_fence_enable_signal(fence); + + if (!fence->ops->enable_signaling(fence)) { + dma_fence_signal_locked(fence); + return false; + } + } + + return true; +} + /** * dma_fence_enable_sw_signaling - enable signaling on fence * @fence: the fence to enable @@ -285,19 +309,12 @@ void dma_fence_enable_sw_signaling(struct dma_fence *fence) { unsigned long flags; - if (!test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, - &fence->flags) && - !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) && - fence->ops->enable_signaling) { - trace_dma_fence_enable_signal(fence); - - spin_lock_irqsave(fence->lock, flags); - - if (!fence->ops->enable_signaling(fence)) - dma_fence_signal_locked(fence); + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + return; - spin_unlock_irqrestore(fence->lock, flags); - } + spin_lock_irqsave(fence->lock, flags); + __dma_fence_enable_signaling(fence); + spin_unlock_irqrestore(fence->lock, flags); } EXPORT_SYMBOL(dma_fence_enable_sw_signaling); @@ -331,7 +348,6 @@ int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb, { unsigned long flags; int ret = 0; - bool was_set; if (WARN_ON(!fence || !func)) return -EINVAL; @@ -343,25 +359,14 @@ int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb, spin_lock_irqsave(fence->lock, flags); - was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, - &fence->flags); - - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) - ret = -ENOENT; - else if (!was_set && fence->ops->enable_signaling) { - trace_dma_fence_enable_signal(fence); - - if (!fence->ops->enable_signaling(fence)) { - dma_fence_signal_locked(fence); - ret = -ENOENT; - } - } - - if (!ret) { + if (__dma_fence_enable_signaling(fence)) { cb->func = func; list_add_tail(&cb->node, &fence->cb_list); - } else + } else { INIT_LIST_HEAD(&cb->node); + ret = -ENOENT; + } + spin_unlock_irqrestore(fence->lock, flags); return ret; @@ -461,7 +466,6 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout) struct default_wait_cb cb; unsigned long flags; signed long ret = timeout ? timeout : 1; - bool was_set; if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) return ret; @@ -473,21 +477,9 @@ dma_fence_default_wait(struct dma_fence *fence, bool intr, signed long timeout) goto out; } - was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, - &fence->flags); - - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) + if (!__dma_fence_enable_signaling(fence)) goto out; - if (!was_set && fence->ops->enable_signaling) { - trace_dma_fence_enable_signal(fence); - - if (!fence->ops->enable_signaling(fence)) { - dma_fence_signal_locked(fence); - goto out; - } - } - if (!timeout) { ret = 0; goto out; -- 2.25.1

5 years, 4 months

1
0
0 0

Changing vma->vm_file in dma_buf_mmap()

by Christian König

Hi Andrew, I'm the new DMA-buf maintainer and Daniel and others came up with patches extending the use of the dma_buf_mmap() function. Now this function is doing something a bit odd by changing the vma->vm_file while installing a VMA in the mmap() system call The background here is that DMA-buf allows device drivers to export buffer which are then imported into another device driver. The mmap() handler of the importing device driver then find that the pgoff belongs to the exporting device and so redirects the mmap() call there. In other words user space calls mmap() on one file descriptor, but get a different one mapped into your virtual address space. My question is now: Is that legal or can you think of something which breaks here? If it's not legal we should probably block any new users of the dma_buf_mmap() function and consider what should happen with the two existing ones. If that is legal I would like to document this by adding a new vma_set_file() function which does the necessary reference count dance. Thanks in advance, Christian.

5 years, 4 months

5
32
0 0

[PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

by Daniel Vetter

GPU drivers need this in their shrinkers, to be able to throw out mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, but that loop is resolved by trylocking in shrinkers. So full hierarchy is now (ignore some of the other branches we already have primed): mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write I hope that's not inconsistent with anything mm or fs does, adding relevant people. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: Dave Chinner <david(a)fromorbit.com> Cc: Qian Cai <cai(a)lca.pw> Cc: linux-xfs(a)vger.kernel.org Cc: linux-fsdevel(a)vger.kernel.org Cc: Thomas Hellström (Intel) <thomas_os(a)shipmail.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: linux-mm(a)kvack.org Cc: linux-rdma(a)vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> --- drivers/dma-buf/dma-resv.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 0e6675ec1d11..9678162a4ac5 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -104,12 +104,14 @@ static int __init dma_resv_lockdep(void) struct mm_struct *mm = mm_alloc(); struct ww_acquire_ctx ctx; struct dma_resv obj; + struct address_space mapping; int ret; if (!mm) return -ENOMEM; dma_resv_init(&obj); + address_space_init_once(&mapping); mmap_read_lock(mm); ww_acquire_init(&ctx, &reservation_ww_class); @@ -117,6 +119,9 @@ static int __init dma_resv_lockdep(void) if (ret == -EDEADLK) dma_resv_lock_slow(&obj, &ctx); fs_reclaim_acquire(GFP_KERNEL); + /* for unmap_mapping_range on trylocked buffer objects in shrinkers */ + i_mmap_lock_write(&mapping); + i_mmap_unlock_write(&mapping); #ifdef CONFIG_MMU_NOTIFIER lock_map_acquire(&__mmu_notifier_invalidate_range_start_map); __dma_fence_might_wait(); -- 2.27.0

5 years, 4 months

4
5
0 0

Re: [Linaro-mm-sig] [PATCH] drm/scheduler: fix sched_fence.c kernel-doc warnings

by Christian König

Am 09.09.20 um 09:57 schrieb Tian Tao: > Fix kernel-doc warnings. > drivers/gpu/drm/scheduler/sched_fence.c:110: warning: Function parameter or > member 'f' not described in 'drm_sched_fence_release_scheduled' > drivers/gpu/drm/scheduler/sched_fence.c:110: warning: Excess function > parameter 'fence' description in 'drm_sched_fence_release_scheduled' > > Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/gpu/drm/scheduler/sched_fence.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c > index 8b45c3a1b84..69de2c7 100644 > --- a/drivers/gpu/drm/scheduler/sched_fence.c > +++ b/drivers/gpu/drm/scheduler/sched_fence.c > @@ -101,7 +101,7 @@ static void drm_sched_fence_free(struct rcu_head *rcu) > /** > * drm_sched_fence_release_scheduled - callback that fence can be freed > * > - * @fence: fence > + * @f: fence > * > * This function is called when the reference count becomes zero. > * It just RCU schedules freeing up the fence.

5 years, 5 months

2
1
0 0

Re: [Linaro-mm-sig] [PATCH v10 30/30] videobuf2: use sgtable-based scatterlist wrappers

by Marek Szyprowski

Hi Tomasz, On 07.09.2020 15:07, Tomasz Figa wrote: > On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski > <m.szyprowski(a)samsung.com> wrote: >> Use recently introduced common wrappers operating directly on the struct >> sg_table objects and scatterlist page iterators to make the code a bit >> more compact, robust, easier to follow and copy/paste safe. >> >> No functional change, because the code already properly did all the >> scatterlist related calls. >> >> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> >> Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> >> --- >> .../common/videobuf2/videobuf2-dma-contig.c | 34 ++++++++----------- >> .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++++++---------- >> .../common/videobuf2/videobuf2-vmalloc.c | 12 +++---- >> 3 files changed, 31 insertions(+), 47 deletions(-) >> > Thanks for the patch! Please see my comments inline. > >> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c >> index ec3446cc45b8..1b242d844dde 100644 >> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c >> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c >> @@ -58,10 +58,10 @@ static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt) >> unsigned int i; >> unsigned long size = 0; >> >> - for_each_sg(sgt->sgl, s, sgt->nents, i) { >> + for_each_sgtable_dma_sg(sgt, s, i) { >> if (sg_dma_address(s) != expected) >> break; >> - expected = sg_dma_address(s) + sg_dma_len(s); >> + expected += sg_dma_len(s); >> size += sg_dma_len(s); >> } >> return size; >> @@ -103,8 +103,7 @@ static void vb2_dc_prepare(void *buf_priv) >> if (!sgt) >> return; >> >> - dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, >> - buf->dma_dir); >> + dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir); >> } >> >> static void vb2_dc_finish(void *buf_priv) >> @@ -115,7 +114,7 @@ static void vb2_dc_finish(void *buf_priv) >> if (!sgt) >> return; >> >> - dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); >> + dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir); >> } >> >> /*********************************************/ >> @@ -275,8 +274,8 @@ static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf, >> * memory locations do not require any explicit cache >> * maintenance prior or after being used by the device. >> */ >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents, >> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, >> + DMA_ATTR_SKIP_CPU_SYNC); >> sg_free_table(sgt); >> kfree(attach); >> db_attach->priv = NULL; >> @@ -301,8 +300,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( >> >> /* release any previous cache */ >> if (attach->dma_dir != DMA_NONE) { >> - dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents, >> - attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC); >> + dma_unmap_sgtable(db_attach->dev, sgt, attach->dma_dir, >> + DMA_ATTR_SKIP_CPU_SYNC); >> attach->dma_dir = DMA_NONE; >> } >> >> @@ -310,9 +309,8 @@ static struct sg_table *vb2_dc_dmabuf_ops_map( >> * mapping to the client with new direction, no cache sync >> * required see comment in vb2_dc_dmabuf_ops_detach() >> */ >> - sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents, >> - dma_dir, DMA_ATTR_SKIP_CPU_SYNC); >> - if (!sgt->nents) { >> + if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, >> + DMA_ATTR_SKIP_CPU_SYNC)) { >> pr_err("failed to map scatterlist\n"); >> mutex_unlock(lock); >> return ERR_PTR(-EIO); > As opposed to dma_map_sg_attrs(), dma_map_sgtable() now returns an > error code on its own. Is it expected to ignore it and return -EIO? Those errors are more or less propagated to userspace and -EIO has been already widely documented in V4L2 documentation as the error code for the most of the V4L2 ioctls. I don't want to change it. A possible -EINVAL returned from dma_map_sgtable() was just one of the 'generic' error codes, not very descriptive in that case. Probably the main problem here is that dma_map_sg() and friend doesn't return any error codes... > ... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

5 years, 5 months

1
0
0 0

[PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse

by Marek Szyprowski

Dear All, During the Exynos DRM GEM rework and fixing the issues in the. drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most drivers in DRM framework incorrectly use nents and orig_nents entries of the struct sg_table. In case of the most DMA-mapping implementations exchanging those two entries or using nents for all loops on the scatterlist is harmless, because they both have the same value. There exists however a DMA-mapping implementations, for which such incorrect usage breaks things. The nents returned by dma_map_sg() might be lower than the nents passed as its parameter and this is perfectly fine. DMA framework or IOMMU is allowed to join consecutive chunks while mapping if such operation is supported by the underlying HW (bus, bridge, IOMMU, etc). Example of the case where dma_map_sg() might return 1 'DMA' chunk for the 4 'physical' pages is described here [2] The DMA-mapping framework documentation [3] states that dma_map_sg() returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of entries passed to dma_map_sg. The common pattern in DRM drivers were to assign the dma_map_sg() return value to sg_table->nents and use that value for the subsequent calls to dma_sync_sg_* or dma_unmap_sg functions. Also the code iterated over nents times to access the pages stored in the processed scatterlist, while it should use orig_nents as the numer of the page entries. I've tried to identify all such incorrect usage of sg_table->nents and this is a result of my research. It looks that the incorrect pattern has been copied over the many drivers mainly in the DRM subsystem. Too bad in most cases it even worked correctly if the system used a simple, linear DMA-mapping implementation, for which swapping nents and orig_nents doesn't make any difference. To avoid similar issues in the future, I've introduced a common wrappers for DMA-mapping calls, which operate directly on the sg_table objects. I've also added wrappers for iterating over the scatterlists stored in the sg_table objects and applied them where possible. This, together with some common DRM prime helpers, allowed me to almost get rid of all nents/orig_nents usage in the drivers. I hope that such change makes the code robust, easier to follow and copy/paste safe. The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix it fully. The driver creatively uses sg_table->orig_nents to store the size of the allocate scatterlist and ignores the number of the entries returned by dma_map_sg function. In this patchset I only fixed the sg_table objects exported by dmabuf related functions. I hope that I didn't break anything there. Patches are based on top of Linux next-20200903. The required changes to DMA-mapping framework has been already merged to v5.9-rc3. If possible I would like ask for merging most of the patches via DRM tree. Best regards, Marek Szyprowski References: [1] https://lkml.org/lkml/2020/3/27/555 [2] https://lkml.org/lkml/2020/3/29/65 [3] Documentation/DMA-API-HOWTO.txt [4] https://lore.kernel.org/linux-iommu/20200512121931.GD20393@lst.de/T/#ma18c9… Changelog: v10: - addressed more issues pointed by Robin Murphy in his review: * prime: restored WARN_ON() in drm_prime_sg_to_page_addr_arrays() * armada: simplified cleanup path * msm: fixed arm64 build * omapdrm: removed WARN_ON(), which is now in drm_prime_sg_to_page_addr_arrays() * omapdrm: dropped the incorrect nents/orig_nents patch * media: pci: also update to use modern DMA_FROM_DEVICE definitions - dropped merged patches v9: https://lore.kernel.org/linux-iommu/20200826063316.23486-1-m.szyprowski@sam… - rebased onto Linux next-20200825, which is based on v5.9-rc2; fixed conflicts - dropped merged patches v8: - rapidio: fixed issues pointed by kbuilt test robot (use of uninitialized variable - vb2: rebased after recent changes in the code v7: https://lore.kernel.org/linux-iommu/20200619103636.11974-1-m.szyprowski@sam… - changed DMA page interators to standard DMA SG iterators in drm/prime and videobuf2-dma-contig as suggested by Robin Murphy - fixed build issues v6: https://lore.kernel.org/linux-iommu/20200618153956.29558-1-m.szyprowski@sam… - rebased onto Linux next-20200618, which is based on v5.8-rc1; fixed conflicts v5: https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@sams… - fixed some minor style issues and typos - fixed lack of the attrs argument in ion, dmabuf, rapidio, fastrpc and vfio patches v4: https://lore.kernel.org/linux-iommu/20200512121931.GD20393@lst.de/T/ - added for_each_sgtable_* wrappers and applied where possible - added drm_prime_get_contiguous_size() and applied where possible - applied drm_prime_sg_to_page_addr_arrays() where possible to remove page extraction from sg_table objects - added documentation for the introduced wrappers - improved patches description a bit v3: https://lore.kernel.org/dri-devel/20200505083926.28503-1-m.szyprowski@samsu… - introduce dma_*_sgtable_* wrappers and use them in all patches v2: https://lore.kernel.org/linux-iommu/c01c9766-9778-fd1f-f36e-2dc7bd376ba4@ar… - dropped most of the changes to drm/i915 - added fixes for rcar-du, xen, media and ion - fixed a few issues pointed by kbuild test robot - added wide cc: list for each patch v1: https://lore.kernel.org/linux-iommu/c01c9766-9778-fd1f-f36e-2dc7bd376ba4@ar… - initial version Patch summary: Marek Szyprowski (30): drm: prime: add common helper to check scatterlist contiguity drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays() drm: core: fix common struct sg_table related issues drm: armada: fix common struct sg_table related issues drm: etnaviv: fix common struct sg_table related issues drm: exynos: use common helper for a scatterlist contiguity check drm: exynos: fix common struct sg_table related issues drm: i915: fix common struct sg_table related issues drm: lima: fix common struct sg_table related issues drm: mediatek: use common helper for a scatterlist contiguity check drm: mediatek: use common helper for extracting pages array drm: msm: fix common struct sg_table related issues drm: omapdrm: use common helper for extracting pages array drm: panfrost: fix common struct sg_table related issues drm: rockchip: use common helper for a scatterlist contiguity check drm: rockchip: fix common struct sg_table related issues drm: tegra: fix common struct sg_table related issues drm: v3d: fix common struct sg_table related issues drm: virtio: fix common struct sg_table related issues drm: vmwgfx: fix common struct sg_table related issues drm: xen: fix common struct sg_table related issues xen: gntdev: fix common struct sg_table related issues drm: host1x: fix common struct sg_table related issues drm: rcar-du: fix common struct sg_table related issues dmabuf: fix common struct sg_table related issues staging: tegra-vde: fix common struct sg_table related issues rapidio: fix common struct sg_table related issues samples: vfio-mdev/mbochs: fix common struct sg_table related issues media: pci: fix common ALSA DMA-mapping related codes videobuf2: use sgtable-based scatterlist wrappers drivers/dma-buf/heaps/heap-helpers.c | 13 ++- drivers/dma-buf/udmabuf.c | 7 +- drivers/gpu/drm/armada/armada_gem.c | 24 +++-- drivers/gpu/drm/drm_cache.c | 2 +- drivers/gpu/drm/drm_gem_cma_helper.c | 23 +---- drivers/gpu/drm/drm_gem_shmem_helper.c | 14 ++- drivers/gpu/drm/drm_prime.c | 91 +++++++++++-------- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 12 +-- drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 15 +-- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +---- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +-- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +- drivers/gpu/drm/lima/lima_gem.c | 11 ++- drivers/gpu/drm/lima/lima_vm.c | 5 +- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 37 ++------ drivers/gpu/drm/msm/msm_gem.c | 13 +-- drivers/gpu/drm/msm/msm_gpummu.c | 15 ++- drivers/gpu/drm/msm/msm_iommu.c | 2 +- drivers/gpu/drm/omapdrm/omap_gem.c | 14 +-- drivers/gpu/drm/panfrost/panfrost_gem.c | 4 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 42 +++------ drivers/gpu/drm/tegra/gem.c | 27 ++---- drivers/gpu/drm/tegra/plane.c | 15 +-- drivers/gpu/drm/v3d/v3d_mmu.c | 13 ++- drivers/gpu/drm/virtio/virtgpu_object.c | 36 +++++--- drivers/gpu/drm/virtio/virtgpu_vq.c | 12 +-- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 17 +--- drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +- drivers/gpu/host1x/job.c | 22 ++--- .../common/videobuf2/videobuf2-dma-contig.c | 34 +++---- .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++---- .../common/videobuf2/videobuf2-vmalloc.c | 12 +-- drivers/media/pci/cx23885/cx23885-alsa.c | 4 +- drivers/media/pci/cx25821/cx25821-alsa.c | 4 +- drivers/media/pci/cx88/cx88-alsa.c | 6 +- drivers/media/pci/saa7134/saa7134-alsa.c | 4 +- drivers/media/platform/vsp1/vsp1_drm.c | 8 +- drivers/rapidio/devices/rio_mport_cdev.c | 11 +-- drivers/staging/media/tegra-vde/iommu.c | 4 +- drivers/xen/gntdev-dmabuf.c | 13 ++- include/drm/drm_prime.h | 2 + samples/vfio-mdev/mbochs.c | 3 +- 45 files changed, 280 insertions(+), 406 deletions(-) -- 2.17.1

5 years, 5 months

2
31
0 0

Re: [Linaro-mm-sig] [PATCH v9 14/32] drm: omapdrm: fix common struct sg_table related issues

by Marek Szyprowski

Hi Tomi, On 02.09.2020 10:00, Tomi Valkeinen wrote: > On 01/09/2020 22:33, Robin Murphy wrote: >> On 2020-08-26 07:32, Marek Szyprowski wrote: >>> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function >>> returns the number of the created entries in the DMA address space. >>> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and >>> dma_unmap_sg must be called with the original number of the entries >>> passed to the dma_map_sg(). >>> >>> struct sg_table is a common structure used for describing a non-contiguous >>> memory buffer, used commonly in the DRM and graphics subsystems. It >>> consists of a scatterlist with memory pages and DMA addresses (sgl entry), >>> as well as the number of scatterlist entries: CPU pages (orig_nents entry) >>> and DMA mapped pages (nents entry). >>> >>> It turned out that it was a common mistake to misuse nents and orig_nents >>> entries, calling DMA-mapping functions with a wrong number of entries or >>> ignoring the number of mapped entries returned by the dma_map_sg() >>> function. >>> >>> Fix the code to refer to proper nents or orig_nents entries. This driver >>> checks for a buffer contiguity in DMA address space, so it should test >>> sg_table->nents entry. >>> >>> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> >>> --- >>> drivers/gpu/drm/omapdrm/omap_gem.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c >>> index ff0c4b0c3fd0..a7a9a0afe2b6 100644 >>> --- a/drivers/gpu/drm/omapdrm/omap_gem.c >>> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c >>> @@ -48,7 +48,7 @@ struct omap_gem_object { >>> * OMAP_BO_MEM_DMA_API flag set) >>> * >>> * - buffers imported from dmabuf (with the OMAP_BO_MEM_DMABUF flag set) >>> - * if they are physically contiguous (when sgt->orig_nents == 1) >>> + * if they are physically contiguous (when sgt->nents == 1) >> Hmm, if this really does mean *physically* contiguous - i.e. if buffers might be shared between >> DMA-translatable and non-DMA-translatable devices - then these changes might not be appropriate. If >> not and it only actually means DMA-contiguous, then it would be good to clarify the comments to that >> effect. >> >> Can anyone familiar with omapdrm clarify what exactly the case is here? I know that IOMMUs might be >> involved to some degree, and I've skimmed the interconnect chapters of enough OMAP TRMs to be scared >> by the reference to the tiler aperture in the context below :) > DSS (like many other IPs in OMAP) does not have any MMU/PAT, and can only use contiguous buffers > (contiguous in the RAM). > > There's a special case with TILER (which is not part of DSS but of the memory subsystem, but it's > still handled internally by the omapdrm driver), which has a PAT. PAT can create a contiguous view > of scattered pages, and DSS can then use this contiguous view ("tiler aperture", which to DSS looks > just like normal contiguous memory). > > Note that omapdrm does not use dma_map_sg() & co. mentioned in the patch description. > > If there's no MMU/PAT, is orig_nents always the same as nents? Or can we have multiple physically > contiguous pages listed separately in the sgt (so orig_nents > 1) but as the pages form one big > contiguous area, nents == 1? Well, when DMA-mapping API is properly used, the difference between nents and orig_nents is only when the scatterlist have been mapped for DMA. For the mentioned case, even if the creator of the buffer used only the pages that are consecutive in the physical memory, he is free to chose either to set nents/orig_nents to 1 and length to n*PAGE_SIZE or set nents/orig_nents to n and length to PAGE_SIZE for each. Then the buffer chunks might be merged, but this is done by the DMA-mapping code. For your case, without any call to DMA-mapping, you can only assume that the buffer is contiguous in physical memory if orig_nents is 1. I've changed the use of nents to orig_nents to make things consistent - this code operates only on the unmapped buffers. I want to ensure that anyone who will potentially copy this code, won't make the nents/orig_nents mistake in the future. If you don't like it, we can drop this patch, because it won't change the way the driver works. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

5 years, 5 months

1
1
0 0

Re: [Linaro-mm-sig] [PATCH 08/29] dma-buf: Avoid comma separated statements

by Christian König

Am 25.08.20 um 06:56 schrieb Joe Perches: > Use semicolons and braces. > > Signed-off-by: Joe Perches <joe(a)perches.com> Acked-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/st-dma-fence.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c > index e593064341c8..c8a12d7ad71a 100644 > --- a/drivers/dma-buf/st-dma-fence.c > +++ b/drivers/dma-buf/st-dma-fence.c > @@ -471,8 +471,11 @@ static int thread_signal_callback(void *arg) > dma_fence_signal(f1); > > smp_store_mb(cb.seen, false); > - if (!f2 || dma_fence_add_callback(f2, &cb.cb, simple_callback)) > - miss++, cb.seen = true; > + if (!f2 || > + dma_fence_add_callback(f2, &cb.cb, simple_callback)) { > + miss++; > + cb.seen = true; > + } > > if (!t->before) > dma_fence_signal(f1);

5 years, 5 months

2
1
0 0

[PATCH v9 00/32] DRM: fix struct sg_table nents vs. orig_nents misuse

by Marek Szyprowski

Dear All, During the Exynos DRM GEM rework and fixing the issues in the. drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most drivers in DRM framework incorrectly use nents and orig_nents entries of the struct sg_table. In case of the most DMA-mapping implementations exchanging those two entries or using nents for all loops on the scatterlist is harmless, because they both have the same value. There exists however a DMA-mapping implementations, for which such incorrect usage breaks things. The nents returned by dma_map_sg() might be lower than the nents passed as its parameter and this is perfectly fine. DMA framework or IOMMU is allowed to join consecutive chunks while mapping if such operation is supported by the underlying HW (bus, bridge, IOMMU, etc). Example of the case where dma_map_sg() might return 1 'DMA' chunk for the 4 'physical' pages is described here [2] The DMA-mapping framework documentation [3] states that dma_map_sg() returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of entries passed to dma_map_sg. The common pattern in DRM drivers were to assign the dma_map_sg() return value to sg_table->nents and use that value for the subsequent calls to dma_sync_sg_* or dma_unmap_sg functions. Also the code iterated over nents times to access the pages stored in the processed scatterlist, while it should use orig_nents as the numer of the page entries. I've tried to identify all such incorrect usage of sg_table->nents and this is a result of my research. It looks that the incorrect pattern has been copied over the many drivers mainly in the DRM subsystem. Too bad in most cases it even worked correctly if the system used a simple, linear DMA-mapping implementation, for which swapping nents and orig_nents doesn't make any difference. To avoid similar issues in the future, I've introduced a common wrappers for DMA-mapping calls, which operate directly on the sg_table objects. I've also added wrappers for iterating over the scatterlists stored in the sg_table objects and applied them where possible. This, together with some common DRM prime helpers, allowed me to almost get rid of all nents/orig_nents usage in the drivers. I hope that such change makes the code robust, easier to follow and copy/paste safe. The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix it fully. The driver creatively uses sg_table->orig_nents to store the size of the allocate scatterlist and ignores the number of the entries returned by dma_map_sg function. In this patchset I only fixed the sg_table objects exported by dmabuf related functions. I hope that I didn't break anything there. Patches are based on top of Linux next-20200825. The required changes to DMA-mapping framework has been already merged to v5.8-rc1. I would like ask for merging of the 1-27 patches via DRM misc tree. Best regards, Marek Szyprowski References: [1] https://lkml.org/lkml/2020/3/27/555 [2] https://lkml.org/lkml/2020/3/29/65 [3] Documentation/DMA-API-HOWTO.txt [4] https://lore.kernel.org/linux-iommu/20200512121931.GD20393@lst.de/T/#ma18c9… Changelog: v9: - rebased onto Linux next-20200825, which is based on v5.9-rc2; fixed conflicts - dropped merged patches v8: - rapidio: fixed issues pointed by kbuilt test robot (use of uninitialized variable - vb2: rebased after recent changes in the code v7: https://lore.kernel.org/linux-iommu/20200619103636.11974-1-m.szyprowski@sam… - changed DMA page interators to standard DMA SG iterators in drm/prime and videobuf2-dma-contig as suggested by Robin Murphy - fixed build issues v6: https://lore.kernel.org/linux-iommu/20200618153956.29558-1-m.szyprowski@sam… - rebased onto Linux next-20200618, which is based on v5.8-rc1; fixed conflicts v5: https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@sams… - fixed some minor style issues and typos - fixed lack of the attrs argument in ion, dmabuf, rapidio, fastrpc and vfio patches v4: https://lore.kernel.org/linux-iommu/20200512121931.GD20393@lst.de/T/ - added for_each_sgtable_* wrappers and applied where possible - added drm_prime_get_contiguous_size() and applied where possible - applied drm_prime_sg_to_page_addr_arrays() where possible to remove page extraction from sg_table objects - added documentation for the introduced wrappers - improved patches description a bit v3: https://lore.kernel.org/dri-devel/20200505083926.28503-1-m.szyprowski@samsu… - introduce dma_*_sgtable_* wrappers and use them in all patches v2: https://lore.kernel.org/linux-iommu/c01c9766-9778-fd1f-f36e-2dc7bd376ba4@ar… - dropped most of the changes to drm/i915 - added fixes for rcar-du, xen, media and ion - fixed a few issues pointed by kbuild test robot - added wide cc: list for each patch v1: https://lore.kernel.org/linux-iommu/c01c9766-9778-fd1f-f36e-2dc7bd376ba4@ar… - initial version Patch summary: Marek Szyprowski (32): drm: prime: add common helper to check scatterlist contiguity drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays() drm: core: fix common struct sg_table related issues drm: armada: fix common struct sg_table related issues drm: etnaviv: fix common struct sg_table related issues drm: exynos: use common helper for a scatterlist contiguity check drm: exynos: fix common struct sg_table related issues drm: i915: fix common struct sg_table related issues drm: lima: fix common struct sg_table related issues drm: mediatek: use common helper for a scatterlist contiguity check drm: mediatek: use common helper for extracting pages array drm: msm: fix common struct sg_table related issues drm: omapdrm: use common helper for extracting pages array drm: omapdrm: fix common struct sg_table related issues drm: panfrost: fix common struct sg_table related issues drm: rockchip: use common helper for a scatterlist contiguity check drm: rockchip: fix common struct sg_table related issues drm: tegra: fix common struct sg_table related issues drm: v3d: fix common struct sg_table related issues drm: virtio: fix common struct sg_table related issues drm: vmwgfx: fix common struct sg_table related issues drm: xen: fix common struct sg_table related issues xen: gntdev: fix common struct sg_table related issues drm: host1x: fix common struct sg_table related issues drm: rcar-du: fix common struct sg_table related issues dmabuf: fix common struct sg_table related issues staging: tegra-vde: fix common struct sg_table related issues misc: fastrpc: fix common struct sg_table related issues rapidio: fix common struct sg_table related issues samples: vfio-mdev/mbochs: fix common struct sg_table related issues media: pci: fix common ALSA DMA-mapping related codes videobuf2: use sgtable-based scatterlist wrappers drivers/dma-buf/heaps/heap-helpers.c | 13 ++- drivers/dma-buf/udmabuf.c | 7 +- drivers/gpu/drm/armada/armada_gem.c | 12 +-- drivers/gpu/drm/drm_cache.c | 2 +- drivers/gpu/drm/drm_gem_cma_helper.c | 23 +---- drivers/gpu/drm/drm_gem_shmem_helper.c | 14 ++- drivers/gpu/drm/drm_prime.c | 91 +++++++++++-------- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 12 +-- drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 13 +-- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 23 +---- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +-- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 7 +- drivers/gpu/drm/lima/lima_gem.c | 11 ++- drivers/gpu/drm/lima/lima_vm.c | 5 +- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 37 ++------ drivers/gpu/drm/msm/msm_gem.c | 13 +-- drivers/gpu/drm/msm/msm_gpummu.c | 14 ++- drivers/gpu/drm/msm/msm_iommu.c | 2 +- drivers/gpu/drm/omapdrm/omap_gem.c | 20 ++-- drivers/gpu/drm/panfrost/panfrost_gem.c | 4 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 42 +++------ drivers/gpu/drm/tegra/gem.c | 27 ++---- drivers/gpu/drm/tegra/plane.c | 15 +-- drivers/gpu/drm/v3d/v3d_mmu.c | 13 ++- drivers/gpu/drm/virtio/virtgpu_object.c | 36 +++++--- drivers/gpu/drm/virtio/virtgpu_vq.c | 12 +-- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 17 +--- drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +- drivers/gpu/host1x/job.c | 22 ++--- .../common/videobuf2/videobuf2-dma-contig.c | 34 +++---- .../media/common/videobuf2/videobuf2-dma-sg.c | 32 +++---- .../common/videobuf2/videobuf2-vmalloc.c | 12 +-- drivers/media/pci/cx23885/cx23885-alsa.c | 2 +- drivers/media/pci/cx25821/cx25821-alsa.c | 2 +- drivers/media/pci/cx88/cx88-alsa.c | 2 +- drivers/media/pci/saa7134/saa7134-alsa.c | 2 +- drivers/media/platform/vsp1/vsp1_drm.c | 8 +- drivers/misc/fastrpc.c | 4 +- drivers/rapidio/devices/rio_mport_cdev.c | 11 +-- drivers/staging/media/tegra-vde/iommu.c | 4 +- drivers/xen/gntdev-dmabuf.c | 13 ++- include/drm/drm_prime.h | 2 + samples/vfio-mdev/mbochs.c | 3 +- 46 files changed, 273 insertions(+), 398 deletions(-) -- 2.17.1

5 years, 5 months

4
56
0 0

Re: [Linaro-mm-sig] [PATCH] staging: ion: remove from the tree

by Greg Kroah-Hartman

On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman > <gregkh(a)linuxfoundation.org> wrote: > > > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > > The ION android code has long been marked to be removed, now that we > > > > dma-buf support merged into the real part of the kernel. > > > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > > quite a bit, and any Android device using the ion interface uses that > > > > forked version and not this in-tree version, the in-tree copy of the > > > > code is abandonded and not used by anyone. > > > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > > order to keep the kernel building properly, which then causes merge > > > > issues when merging those changes into the out-of-tree Android code, and > > > > you end up with two different groups of people (the in-kernel-tree > > > > developers, and the Android kernel developers) who are both annoyed at > > > > the current situation. Because of this problem, just drop the in-kernel > > > > copy of the ion code now, as it's not used, and is only causing problems > > > > for everyone involved. > > > > > > > > Cc: "Arve Hjønnevåg" <arve(a)android.com> > > > > Cc: "Christian König" <christian.koenig(a)amd.com> > > > > Cc: Christian Brauner <christian(a)brauner.io> > > > > Cc: Christoph Hellwig <hch(a)infradead.org> > > > > Cc: Hridya Valsaraju <hridya(a)google.com> > > > > Cc: Joel Fernandes <joel(a)joelfernandes.org> > > > > Cc: John Stultz <john.stultz(a)linaro.org> > > > > Cc: Laura Abbott <laura(a)labbott.name> > > > > Cc: Martijn Coenen <maco(a)android.com> > > > > Cc: Shuah Khan <shuah(a)kernel.org> > > > > Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > > > > Cc: Suren Baghdasaryan <surenb(a)google.com> > > > > Cc: Todd Kjos <tkjos(a)android.com> > > > > Cc: devel(a)driverdev.osuosl.org > > > > Cc: dri-devel(a)lists.freedesktop.org > > > > Cc: linaro-mm-sig(a)lists.linaro.org > > > > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > > > > > > We discussed this at the Android MC on Monday and the plan was to > > > remove it after the next LTS release. > > > > I know it was discussed, my point is that it is actually causing > > problems now (with developers who want to change the internal kernel api > > hitting issues, and newbies trying to clean up code in ways that isn't > > exactly optimal wasting maintainer cycles), and that anyone who uses > > this code, is not actually using this version of the code. Everyone who > > relies on ion right now, is using the version that is in the Android > > common kernel tree, which has diverged from this in-kernel way quite a > > bit now for the reason that we didn't want to take any of those new > > features in the in-kernel version. > > > > So this is a problem that we have caused by just wanting to wait, no one > > is using this code, combined with it causing problems for the upstream > > developers. > > > > There is nothing "magic" about the last kernel of the year that requires > > this code to sit here until then. At that point in time, all users > > will, again, be using the forked Android kernel version, and if we > > delete this now here, that fork can remain just fine, with the added > > benifit of it reducing developer workloads here in-kernel. > > > > So why wait? > > Hi, > > I don't know what is the right thing to do here. I just want to > highlight that AOSP's audio (codec2) HAL depends on the ION system > heap and it will break AOSP for people who boot mainline on their > devices, even for just testing purpose like we do in Linaro. Right now > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > mainline and Sumit is already trying to upstream that vma naming > patch. Removal of in-kernel ION, will just add more to that delta. As AOSP will continue to rely on ION after December of this year, all you are doing is postponing the inevitable a few more months. Push back on the Android team to fix up the code to not use ION, they know this needs to happen. thanks, greg k-h

5 years, 5 months

3
4
0 0

Re: [Linaro-mm-sig] [PATCH] staging: ion: remove from the tree

by Greg Kroah-Hartman

On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > The ION android code has long been marked to be removed, now that we > > dma-buf support merged into the real part of the kernel. > > > > It was thought that we could wait to remove the ion kernel at a later > > time, but as the out-of-tree Android fork of the ion code has diverged > > quite a bit, and any Android device using the ion interface uses that > > forked version and not this in-tree version, the in-tree copy of the > > code is abandonded and not used by anyone. > > > > Combine this abandoned codebase with the need to make changes to it in > > order to keep the kernel building properly, which then causes merge > > issues when merging those changes into the out-of-tree Android code, and > > you end up with two different groups of people (the in-kernel-tree > > developers, and the Android kernel developers) who are both annoyed at > > the current situation. Because of this problem, just drop the in-kernel > > copy of the ion code now, as it's not used, and is only causing problems > > for everyone involved. > > > > Cc: "Arve Hjønnevåg" <arve(a)android.com> > > Cc: "Christian König" <christian.koenig(a)amd.com> > > Cc: Christian Brauner <christian(a)brauner.io> > > Cc: Christoph Hellwig <hch(a)infradead.org> > > Cc: Hridya Valsaraju <hridya(a)google.com> > > Cc: Joel Fernandes <joel(a)joelfernandes.org> > > Cc: John Stultz <john.stultz(a)linaro.org> > > Cc: Laura Abbott <laura(a)labbott.name> > > Cc: Martijn Coenen <maco(a)android.com> > > Cc: Shuah Khan <shuah(a)kernel.org> > > Cc: Sumit Semwal <sumit.semwal(a)linaro.org> > > Cc: Suren Baghdasaryan <surenb(a)google.com> > > Cc: Todd Kjos <tkjos(a)android.com> > > Cc: devel(a)driverdev.osuosl.org > > Cc: dri-devel(a)lists.freedesktop.org > > Cc: linaro-mm-sig(a)lists.linaro.org > > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > > We discussed this at the Android MC on Monday and the plan was to > remove it after the next LTS release. I know it was discussed, my point is that it is actually causing problems now (with developers who want to change the internal kernel api hitting issues, and newbies trying to clean up code in ways that isn't exactly optimal wasting maintainer cycles), and that anyone who uses this code, is not actually using this version of the code. Everyone who relies on ion right now, is using the version that is in the Android common kernel tree, which has diverged from this in-kernel way quite a bit now for the reason that we didn't want to take any of those new features in the in-kernel version. So this is a problem that we have caused by just wanting to wait, no one is using this code, combined with it causing problems for the upstream developers. There is nothing "magic" about the last kernel of the year that requires this code to sit here until then. At that point in time, all users will, again, be using the forked Android kernel version, and if we delete this now here, that fork can remain just fine, with the added benifit of it reducing developer workloads here in-kernel. So why wait? thanks, greg k-h

5 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap

by John Stultz

On Fri, Aug 21, 2020 at 2:14 AM Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com> wrote: > > On 2020/08/01 4:38, John Stultz wrote: > > On Fri, Jul 31, 2020 at 2:32 AM Kunihiko Hayashi > > <hayashi.kunihiko(a)socionext.com> wrote: > >> On 2020/07/29 4:17, John Stultz wrote: > >>> Do you have a upstream driver that you plan to make use this new call? > >> > >> Unfortunately I don't have an upstream driver using this call. > >> > >> This call is called from dma-buf heaps "importer" or "customer", > >> and I only made an example (do nothing) importer driver > >> to test the call. > >> > >>> We want to have in-tree users of code added. > >> > >> I think this is a generic way to use non-default CMA heaps, however, > >> we need in-tree "importer" drivers to want to use non-default CMA heaps. > >> I don't find it from now. > >> > > > > Yea, I and again, I do agree this is functionality that will be > > needed. But we'll need to wait for a user (camera driver, etc which > > would utilize the reserved cma region) before we can merge it > > upstream. :( Do let me know if you have an out of tree driver that > > would make use of it, and we can see what can be done to help upstream > > things. > > Sorry for late. > Before I prepare or find a user driver as "importer", > I think something is different in this patch. > > This patch makes it possible to treat non-default CMA connected to > "importer" device with memory-region as dma-buf heaps. > > However, the allocated memory from this dma-buf heaps can be used > for "any" devices, and the "importer" can treat memories from other > dma-buf heaps. > > So, the "importer" and the non-default CMA aren't directly related, > and I think an "exporter" for the non-default CMA should be enabled. > > In paticular, the kernel initializer (as an "exporter") calls > dma_heap_add_cma() for all CMAs defined in Devicetree, and > the device files associated with each CMA appear under "/dev/dma_heap/". > For example: > > /dev/dma_heap/linux,cma@10000000 > /dev/dma_heap/linux,cma@11000000 > /dev/dma_heap/linux,cma@12000000 > ... > > All of these device files can be fairly allocated to any "importer" device. > > Actually I think that the kernel should executes dma_heap_add_cma() > for ALL defined reserved-memory nodes. > > If this idea hasn't been discussed yet and this is reasonable, > I'll prepare RFC patches. So yes! An earlier version of the CMA heap I submitted did add all CMA regions as accessible heaps as you propose here. However, the concern was that in some cases, those regions are device specific reserved memory that the driver is probably expecting to have exclusive access. To allow (sufficiently privileged, or misconfigured) userland to be able to allocate out of that seemed like it might cause trouble, and instead we should have CMA regions explicitly exported. There was some proposal to add a dt property to the reserved memory section (similar to linux,cma-default) and use that to do the exporting, but other discussions seemed to prefer having drivers export it explicitly in a fashion very similar to what your earlier patch does. The only trouble is we just need an upstream driver to add such a call in the series before we can merge it. thanks -john

5 years, 5 months

1
0
0 0

[PATCH 0/3] Chunk Heap Support on DMA-HEAP

by Hyesoo Yu

These patch series to introduce a new dma heap, chunk heap. That heap is needed for special HW that requires bulk allocation of fixed high order pages. For example, 64MB dma-buf pages are made up to fixed order-4 pages * 1024. The chunk heap uses alloc_pages_bulk to allocate high order page. https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minchan@kernel.org The chunk heap is registered by device tree with alignment and memory node of contiguous memory allocator(CMA). Alignment defines chunk page size. For example, alignment 0x1_0000 means chunk page size is 64KB. The phandle to memory node indicates contiguous memory allocator(CMA). If device node doesn't have cma, the registration of chunk heap fails. The patchset includes the following: - export dma-heap API to register kernel module dma heap. - add chunk heap implementation. - document of device tree to register chunk heap Hyesoo Yu (3): dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps dma-buf: heaps: add chunk heap to dmabuf heaps dma-heap: Devicetree binding for chunk heap .../devicetree/bindings/dma-buf/chunk_heap.yaml | 46 +++++ drivers/dma-buf/dma-heap.c | 2 + drivers/dma-buf/heaps/Kconfig | 9 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/chunk_heap.c | 222 +++++++++++++++++++++ drivers/dma-buf/heaps/heap-helpers.c | 2 + 6 files changed, 282 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml create mode 100644 drivers/dma-buf/heaps/chunk_heap.c -- 2.7.4

5 years, 5 months

6
11
0 0

[RESEND PATCH 1/2] dma-buf: Fix kerneldoc of dma_buf_set_name()

by Krzysztof Kozlowski

Fix W=1 compile warnings (invalid kerneldoc): drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member 'dmabuf' not described in 'dma_buf_set_name' Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- drivers/dma-buf/dma-buf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 1699a8e309ef..58564d82a3a2 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -316,9 +316,9 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) * name of the dma-buf if the same piece of memory is used for multiple * purpose between different devices. * - * @dmabuf [in] dmabuf buffer that will be renamed. - * @buf: [in] A piece of userspace memory that contains the name of - * the dma-buf. + * @dmabuf: [in] dmabuf buffer that will be renamed. + * @buf: [in] A piece of userspace memory that contains the name of + * the dma-buf. * * Returns 0 on success. If the dma-buf buffer is already attached to * devices, return -EBUSY. -- 2.17.1

5 years, 5 months

2
2
0 0

Re: [Linaro-mm-sig] [PATCH 0/4] *** SUBJECT HERE ***

by Greg Kroah-Hartman

On Tue, Aug 18, 2020 at 12:17:08PM +0300, Tomer Samara wrote: > *** BLURB HERE *** Really? And your subject line could use some work too :(

5 years, 6 months

1
0
0 0

[PATCH v7 0/3] Support virtio cross-device resources

by David Stevens

This patchset implements the current proposal for virtio cross-device resource sharing [1]. It will be used to import virtio resources into the virtio-video driver currently under discussion [2]. The patch under consideration to add support in the virtio-video driver is [3]. It uses the APIs from v3 of this series, but the changes to update it are relatively minor. This patchset adds a new flavor of dma-bufs that supports querying the underlying virtio object UUID, as well as adding support for exporting resources from virtgpu. [1] https://markmail.org/thread/2ypjt5cfeu3m6lxu [2] https://markmail.org/thread/p5d3k566srtdtute [3] https://markmail.org/thread/j4xlqaaim266qpks v6 -> v7 changes: - Fix most strict checkpatch comments David Stevens (3): virtio: add dma-buf support for exported objects virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature drm/virtio: Support virtgpu exported resources drivers/gpu/drm/virtio/virtgpu_drv.c | 3 + drivers/gpu/drm/virtio/virtgpu_drv.h | 21 ++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 96 +++++++++++++++++++++++++- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 +++++++++++++++ drivers/virtio/Makefile | 2 +- drivers/virtio/virtio.c | 6 ++ drivers/virtio/virtio_dma_buf.c | 85 +++++++++++++++++++++++ include/linux/virtio.h | 1 + include/linux/virtio_dma_buf.h | 37 ++++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++ 11 files changed, 325 insertions(+), 4 deletions(-) create mode 100644 drivers/virtio/virtio_dma_buf.c create mode 100644 include/linux/virtio_dma_buf.h -- 2.28.0.220.ged08abb693-goog

5 years, 6 months

1
3
0 0

[PATCH v6 0/3] Support virtio cross-device resources

by David Stevens

This patchset implements the current proposal for virtio cross-device resource sharing [1]. It will be used to import virtio resources into the virtio-video driver currently under discussion [2]. The patch under consideration to add support in the virtio-video driver is [3]. It uses the APIs from v3 of this series, but the changes to update it are relatively minor. This patchset adds a new flavor of dma-bufs that supports querying the underlying virtio object UUID, as well as adding support for exporting resources from virtgpu. [1] https://markmail.org/thread/2ypjt5cfeu3m6lxu [2] https://markmail.org/thread/p5d3k566srtdtute [3] https://markmail.org/thread/j4xlqaaim266qpks v5 -> v6 changes: - Fix >80 character comment David Stevens (3): virtio: add dma-buf support for exported objects virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature drm/virtio: Support virtgpu exported resources drivers/gpu/drm/virtio/virtgpu_drv.c | 3 + drivers/gpu/drm/virtio/virtgpu_drv.h | 20 ++++++ drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ drivers/gpu/drm/virtio/virtgpu_prime.c | 96 +++++++++++++++++++++++++- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 +++++++++++++++ drivers/virtio/Makefile | 2 +- drivers/virtio/virtio.c | 6 ++ drivers/virtio/virtio_dma_buf.c | 82 ++++++++++++++++++++++ include/linux/virtio.h | 1 + include/linux/virtio_dma_buf.h | 37 ++++++++++ include/uapi/linux/virtio_gpu.h | 19 +++++ 11 files changed, 321 insertions(+), 4 deletions(-) create mode 100644 drivers/virtio/virtio_dma_buf.c create mode 100644 include/linux/virtio_dma_buf.h -- 2.28.0.220.ged08abb693-goog

5 years, 6 months

2
5
0 0

Re: [Linaro-mm-sig] [virtio-dev] Re: [PATCH v5 0/3] Support virtio cross-device resources

by David Stevens

Unless there are any remaining objections to these patches, what are the next steps towards getting these merged? Sorry, I'm not familiar with the workflow for contributing patches to Linux. Thanks, David On Tue, Jun 9, 2020 at 6:53 PM Michael S. Tsirkin <mst(a)redhat.com> wrote: > > On Tue, Jun 09, 2020 at 10:25:15AM +0900, David Stevens wrote: > > This patchset implements the current proposal for virtio cross-device > > resource sharing [1]. It will be used to import virtio resources into > > the virtio-video driver currently under discussion [2]. The patch > > under consideration to add support in the virtio-video driver is [3]. > > It uses the APIs from v3 of this series, but the changes to update it > > are relatively minor. > > > > This patchset adds a new flavor of dma-bufs that supports querying the > > underlying virtio object UUID, as well as adding support for exporting > > resources from virtgpu. > > Gerd, David, if possible, please test this in configuration with > virtual VTD enabled but with iommu_platform=off > to make sure we didn't break this config. > > > Besides that, for virtio parts: > > Acked-by: Michael S. Tsirkin <mst(a)redhat.com> > > > > [1] https://markmail.org/thread/2ypjt5cfeu3m6lxu > > [2] https://markmail.org/thread/p5d3k566srtdtute > > [3] https://markmail.org/thread/j4xlqaaim266qpks > > > > v4 -> v5 changes: > > - Remove virtio_dma_buf_export_info. > > > > David Stevens (3): > > virtio: add dma-buf support for exported objects > > virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature > > drm/virtio: Support virtgpu exported resources > > > > drivers/gpu/drm/virtio/virtgpu_drv.c | 3 + > > drivers/gpu/drm/virtio/virtgpu_drv.h | 20 ++++++ > > drivers/gpu/drm/virtio/virtgpu_kms.c | 4 ++ > > drivers/gpu/drm/virtio/virtgpu_prime.c | 96 +++++++++++++++++++++++++- > > drivers/gpu/drm/virtio/virtgpu_vq.c | 55 +++++++++++++++ > > drivers/virtio/Makefile | 2 +- > > drivers/virtio/virtio.c | 6 ++ > > drivers/virtio/virtio_dma_buf.c | 82 ++++++++++++++++++++++ > > include/linux/virtio.h | 1 + > > include/linux/virtio_dma_buf.h | 37 ++++++++++ > > include/uapi/linux/virtio_gpu.h | 19 +++++ > > 11 files changed, 321 insertions(+), 4 deletions(-) > > create mode 100644 drivers/virtio/virtio_dma_buf.c > > create mode 100644 include/linux/virtio_dma_buf.h > > > > -- > > 2.27.0.278.ge193c7cf3a9-goog > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: virtio-dev-unsubscribe(a)lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help(a)lists.oasis-open.org >

5 years, 6 months

2
3
0 0

[RFC PATCH v1] dma-fence-array: Deal with sub-fences that are signaled late

by Jordan Crouse

This is an RFC because I'm still trying to grok the correct behavior. Consider a dma_fence_array created two two fence and signal_on_any is true. A reference to dma_fence_array is taken for each waiting fence. When the client calls dma_fence_wait() only one of the fences is signaled. The client returns successfully from the wait and puts it's reference to the array fence but the array fence still remains because of the remaining un-signaled fence. Now consider that the unsignaled fence is signaled while the timeline is being destroyed much later. The timeline destroy calls dma_fence_signal_locked(). The following sequence occurs: 1) dma_fence_array_cb_func is called 2) array->num_pending is 0 (because it was set to 1 due to signal_on_any) so the callback function calls dma_fence_put() instead of triggering the irq work 3) The array fence is released which in turn puts the lingering fence which is then released 4) deadlock with the timeline I think that we can fix this with the attached patch. Once the fence is signaled signaling it again in the irq worker shouldn't hurt anything. The only gotcha might be how the error is propagated - I wasn't quite sure the intent of clearing it only after getting to the irq worker. Signed-off-by: Jordan Crouse <jcrouse(a)codeaurora.org> --- drivers/dma-buf/dma-fence-array.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index d3fbd950be94..b8829b024255 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -46,8 +46,6 @@ static void irq_dma_fence_array_work(struct irq_work *wrk) { struct dma_fence_array *array = container_of(wrk, typeof(*array), work); - dma_fence_array_clear_pending_error(array); - dma_fence_signal(&array->base); dma_fence_put(&array->base); } @@ -61,10 +59,10 @@ static void dma_fence_array_cb_func(struct dma_fence *f, dma_fence_array_set_pending_error(array, f->error); - if (atomic_dec_and_test(&array->num_pending)) - irq_work_queue(&array->work); - else - dma_fence_put(&array->base); + if (!atomic_dec_and_test(&array->num_pending)) + dma_fence_array_set_pending_error(array, f->error); + + irq_work_queue(&array->work); } static bool dma_fence_array_enable_signaling(struct dma_fence *fence) -- 2.25.1

5 years, 6 months

3
3
0 0

[PATCH] dma-buf.rst: repair length of title underline

by Lukas Bulwahn

With commit 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad idea"), document generation warns: Documentation/driver-api/dma-buf.rst:182: \ WARNING: Title underline too short. Repair length of title underline to remove warning. Fixes: 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad idea") Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)gmail.com> --- Daniel, please pick this minor non-urgent fix to your new documentation. Documentation/driver-api/dma-buf.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 100bfd227265..13ea0cc0a3fa 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -179,7 +179,7 @@ DMA Fence uABI/Sync File :internal: Indefinite DMA Fences -~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~ At various times &dma_fence with an indefinite time until dma_fence_wait() finishes have been proposed. Examples include: -- 2.17.1

5 years, 6 months

3
2
0 0

Re: [Linaro-mm-sig] [PATCH v3] drm/virtio: fix missing dma_fence_put() in virtio_gpu_execbuffer_ioctl()

by Gerd Hoffmann

On Tue, Jul 21, 2020 at 06:16:47PM +0800, Xin He wrote: > From: Qi Liu <liuqi.16(a)bytedance.com> > > We should put the reference count of the fence after calling > virtio_gpu_cmd_submit(). So add the missing dma_fence_put(). > virtio_gpu_cmd_submit(vgdev, buf, exbuf->size, > vfpriv->ctx_id, buflist, out_fence); > + dma_fence_put(&out_fence->f); > virtio_gpu_notify(vgdev); Pushed to drm-misc-fixes. thanks, Gerd

5 years, 6 months

1
0
0 0

[PATCH] staging: ion: fix spelling mistake in function name "detatch" -> "detach"

by Colin King

From: Colin Ian King <colin.king(a)canonical.com> There is a spelling mistake in the function name ion_dma_buf_detatch. Fix it by removing the extraneous t. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/staging/android/ion/ion.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 3c9f09506ffa..e1fe03ceb7f1 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -205,8 +205,8 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf, return 0; } -static void ion_dma_buf_detatch(struct dma_buf *dmabuf, - struct dma_buf_attachment *attachment) +static void ion_dma_buf_detach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) { struct ion_dma_buf_attachment *a = attachment->priv; struct ion_buffer *buffer = dmabuf->priv; @@ -331,7 +331,7 @@ static const struct dma_buf_ops dma_buf_ops = { .mmap = ion_mmap, .release = ion_dma_buf_release, .attach = ion_dma_buf_attach, - .detach = ion_dma_buf_detatch, + .detach = ion_dma_buf_detach, .begin_cpu_access = ion_dma_buf_begin_cpu_access, .end_cpu_access = ion_dma_buf_end_cpu_access, }; -- 2.27.0

5 years, 6 months

2
1
0 0

[PATCH 0/2] Per process tracking of dma buffers

by Kalesh Singh

Since debugfs doesn't have stable abi. This patch series enables per process accounting of dma buffers using trace events. Kalesh Singh (2): fs: Add fd_install file operation dmabuf/tracing: Add dma-buf trace events Documentation/filesystems/vfs.rst | 5 ++ drivers/dma-buf/dma-buf.c | 29 ++++++++++++ fs/file.c | 3 ++ include/linux/fs.h | 1 + include/trace/events/dma_buf.h | 77 +++++++++++++++++++++++++++++++ 5 files changed, 115 insertions(+) create mode 100644 include/trace/events/dma_buf.h -- 2.28.0.163.g6104cc2f0b6-goog

5 years, 6 months

7
18
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig