Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

17 participants
3188 discussions

[PATCH] dma-buf: WIP dma_fence_array_first fix

by Christian König

Looks like somebody is creating an empty dma_fence_array. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence-array.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 52b85d292383..5c8a7084577b 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -159,6 +159,8 @@ struct dma_fence_array *dma_fence_array_create(int num_fences, struct dma_fence_array *array; size_t size = sizeof(*array); + WARN_ON(!num_fences || !fences); + /* Allocate the callback structures behind the array. */ size += num_fences * sizeof(struct dma_fence_array_cb); array = kzalloc(size, GFP_KERNEL); @@ -231,6 +233,9 @@ struct dma_fence *dma_fence_array_first(struct dma_fence *head) if (!array) return head; + if (!array->num_fences) + return NULL; + return array->fences[0]; } EXPORT_SYMBOL(dma_fence_array_first); -- 2.25.1

3 years, 8 months

Re: [RFC v3 5/8] dmabuf: Add gpu cgroup charge transfer function

by Michal Koutný

On Mon, Mar 21, 2022 at 04:54:26PM -0700, "T.J. Mercier" <tjmercier(a)google.com> wrote: > Since the charge is duplicated in two cgroups for a short period > before it is uncharged from the source cgroup I guess the situation > you're thinking about is a global (or common ancestor) limit? The common ancestor was on my mind (after the self-shortcut). > I can see how that would be a problem for transfers done this way and > an alternative would be to swap the order of the charge operations: > first uncharge, then try_charge. To be certain the uncharge is > reversible if the try_charge fails, I think I'd need either a mutex > used at all gpucg_*charge call sites or access to the gpucg_mutex, Yes, that'd provide safe conditions for such operations, although I'm not sure these special types of memory can afford global lock on their fast paths. > which implies adding transfer support to gpu.c as part of the gpucg_* > API itself and calling it here. Am I following correctly here? My idea was to provide a special API (apart from gpucp_{try_charge,uncharge}) to facilitate transfers... > This series doesn't actually add limit support just accounting, but > I'd like to get it right here. ...which could be implemented (or changed) depending on how the charging is realized internally. Michal

3 years, 8 months

[PATCH 04/23] RDMA: use dma_resv_wait() instead of extracting the fence

by Christian König

Use dma_resv_wait() instead of extracting the exclusive fence and waiting on it manually. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Leon Romanovsky <leon(a)kernel.org> Cc: Maor Gottlieb <maorg(a)nvidia.com> Cc: Gal Pressman <galpress(a)amazon.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/infiniband/core/umem_dmabuf.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c index f0760741f281..d32cd7538835 100644 --- a/drivers/infiniband/core/umem_dmabuf.c +++ b/drivers/infiniband/core/umem_dmabuf.c @@ -16,7 +16,6 @@ int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) { struct sg_table *sgt; struct scatterlist *sg; - struct dma_fence *fence; unsigned long start, end, cur = 0; unsigned int nmap = 0; int i; @@ -68,11 +67,8 @@ 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. */ - fence = dma_resv_excl_fence(umem_dmabuf->attach->dmabuf->resv); - if (fence) - return dma_fence_wait(fence, false); - - return 0; + return dma_resv_wait_timeout(umem_dmabuf->attach->dmabuf->resv, false, + false, MAX_SCHEDULE_TIMEOUT); } EXPORT_SYMBOL(ib_umem_dmabuf_map_pages); -- 2.25.1

3 years, 8 months

[RFC v3 0/8] Proposal for a GPU cgroup controller

by T.J. Mercier

This patch series revisits the proposal for a GPU cgroup controller to track and limit memory allocations by various device/allocator subsystems. The patch series also contains a simple prototype to illustrate how Android intends to implement DMA-BUF allocator attribution using the GPU cgroup controller. The prototype does not include resource limit enforcements. Changelog: v3: Remove Upstreaming Plan from gpu-cgroup.rst per John Stultz Use more common dual author commit message format per John Stultz Remove android from binder changes title per Todd Kjos Add a kselftest for this new behavior per Greg Kroah-Hartman Include details on behavior for all combinations of kernel/userspace versions in changelog (thanks Suren Baghdasaryan) per Greg Kroah-Hartman. Fix pid and uid types in binder UAPI header v2: See the previous revision of this change submitted by Hridya Valsaraju at: https://lore.kernel.org/all/20220115010622.3185921-1-hridya@google.com/ Move dma-buf cgroup charge transfer from a dma_buf_op defined by every heap to a single dma-buf function for all heaps per Daniel Vetter and Christian König. Pointers to struct gpucg and struct gpucg_device tracking the current associations were added to the dma_buf struct to achieve this. Fix incorrect Kconfig help section indentation per Randy Dunlap. History of the GPU cgroup controller ==================================== The GPU/DRM cgroup controller came into being when a consensus[1] was reached that the resources it tracked were unsuitable to be integrated into memcg. Originally, the proposed controller was specific to the DRM subsystem and was intended to track GEM buffers and GPU-specific resources[2]. In order to help establish a unified memory accounting model for all GPU and all related subsystems, Daniel Vetter put forth a suggestion to move it out of the DRM subsystem so that it can be used by other DMA-BUF exporters as well[3]. This RFC proposes an interface that does the same. [1]: https://patchwork.kernel.org/project/dri-devel/cover/20190501140438.9506-1-… [2]: https://lore.kernel.org/amd-gfx/20210126214626.16260-1-brian.welty@intel.co… [3]: https://lore.kernel.org/amd-gfx/YCVOl8%2F87bqRSQei@phenom.ffwll.local/ Hridya Valsaraju (5): gpu: rfc: Proposal for a GPU cgroup controller cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory dmabuf: heaps: export system_heap buffers with GPU cgroup charging dmabuf: Add gpu cgroup charge transfer function binder: Add a buffer flag to relinquish ownership of fds T.J. Mercier (3): dmabuf: Use the GPU cgroup charge/uncharge APIs binder: use __kernel_pid_t and __kernel_uid_t for userspace selftests: Add binder cgroup gpu memory transfer test Documentation/gpu/rfc/gpu-cgroup.rst | 183 +++++++ Documentation/gpu/rfc/index.rst | 4 + drivers/android/binder.c | 26 + drivers/dma-buf/dma-buf.c | 100 ++++ drivers/dma-buf/dma-heap.c | 27 + drivers/dma-buf/heaps/system_heap.c | 3 + include/linux/cgroup_gpu.h | 127 +++++ include/linux/cgroup_subsys.h | 4 + include/linux/dma-buf.h | 22 +- include/linux/dma-heap.h | 11 + include/uapi/linux/android/binder.h | 5 +- init/Kconfig | 7 + kernel/cgroup/Makefile | 1 + kernel/cgroup/gpu.c | 304 +++++++++++ .../selftests/drivers/android/binder/Makefile | 8 + .../drivers/android/binder/binder_util.c | 254 +++++++++ .../drivers/android/binder/binder_util.h | 32 ++ .../selftests/drivers/android/binder/config | 4 + .../binder/test_dmabuf_cgroup_transfer.c | 480 ++++++++++++++++++ 19 files changed, 1598 insertions(+), 4 deletions(-) create mode 100644 Documentation/gpu/rfc/gpu-cgroup.rst create mode 100644 include/linux/cgroup_gpu.h create mode 100644 kernel/cgroup/gpu.c create mode 100644 tools/testing/selftests/drivers/android/binder/Makefile create mode 100644 tools/testing/selftests/drivers/android/binder/binder_util.c create mode 100644 tools/testing/selftests/drivers/android/binder/binder_util.h create mode 100644 tools/testing/selftests/drivers/android/binder/config create mode 100644 tools/testing/selftests/drivers/android/binder/test_dmabuf_cgroup_transfer.c -- 2.35.1.616.g0bdcbb4464-goog

3 years, 8 months

[PATCH] gpu: drm: Fix duplicate included linux/module.h

by Haowen Bai

Clean up the following includecheck warning: drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. No functional change. Signed-off-by: Haowen Bai <baihaowen(a)meizu.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 62192411..7915047 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 2.7.4

3 years, 8 months

[syzbot] WARNING in drm_prime_destroy_file_private

by syzbot

Hello, syzbot found the following issue on: HEAD commit: ea4424be1688 Merge tag 'mtd/fixes-for-5.17-rc8' of git://g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14095f9e700000 kernel config: https://syzkaller.appspot.com/x/.config?x=aba0ab2928a512c2 dashboard link: https://syzkaller.appspot.com/bug?extid=2448673875b4e20db46a compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+2448673875b4e20db46a(a)syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 1 PID: 16791 at drivers/gpu/drm/drm_prime.c:228 drm_prime_destroy_file_private+0x3e/0x50 drivers/gpu/drm/drm_prime.c:228 Modules linked in: CPU: 1 PID: 16791 Comm: syz-executor.5 Not tainted 5.17.0-rc7-syzkaller-00020-gea4424be1688 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:drm_prime_destroy_file_private+0x3e/0x50 drivers/gpu/drm/drm_prime.c:228 Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 1f 48 8b 83 90 00 00 00 48 85 c0 75 06 5b e9 e7 6c 1d fd e8 e2 6c 1d fd <0f> 0b 5b e9 da 6c 1d fd e8 05 5a 64 fd eb da 0f 1f 00 41 55 49 89 RSP: 0018:ffffc90002af79e0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888025e72370 RCX: 0000000000000000 RDX: ffff8880727aa1c0 RSI: ffffffff845a788e RDI: ffff888025e72400 RBP: ffff8881471d4068 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff817e23e8 R11: 0000000000088078 R12: ffff888025e72000 R13: ffff888025e722b8 R14: ffff8881471d4098 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffea39ef0d8 CR3: 00000000791d8000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> drm_file_free.part.0+0x6e5/0xb80 drivers/gpu/drm/drm_file.c:291 drm_file_free drivers/gpu/drm/drm_file.c:248 [inline] drm_close_helper.isra.0+0x17d/0x1f0 drivers/gpu/drm/drm_file.c:308 drm_release+0x1e6/0x530 drivers/gpu/drm/drm_file.c:495 __fput+0x286/0x9f0 fs/file_table.c:317 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xb29/0x2a30 kernel/exit.c:806 do_group_exit+0xd2/0x2f0 kernel/exit.c:935 get_signal+0x45a/0x2490 kernel/signal.c:2863 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:288 RIP: 0033:0x7f836c6a0471 Code: Unable to access opcode bytes at RIP 0x7f836c6a0447. RSP: 002b:00007f836afd22f0 EFLAGS: 00000206 ORIG_RAX: 0000000000000038 RAX: 0000000000000000 RBX: 00007f836afd2700 RCX: 00007f836c6a0471 RDX: 00007f836afd29d0 RSI: 00007f836afd22f0 RDI: 00000000003d0f00 RBP: 00007ffed5e285a0 R08: 00007f836afd2700 R09: 00007f836afd2700 R10: 00007f836afd29d0 R11: 0000000000000206 R12: 00007ffed5e2840e R13: 00007ffed5e2840f R14: 00007f836afd2300 R15: 0000000000022000 </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

3 years, 8 months

[PATCH] dma-fence: fix free sync object incorrectly

by wangshumin

The function dma_fence_free() works fine because struct dma_fence is the first member of sync object. Use `kfree` make it more reasonable. Signed-off-by: wangshumin <pdsrazor(a)gmail.com> --- drivers/dma-buf/dma-fence-array.c | 2 +- drivers/dma-buf/dma-fence-chain.c | 2 +- drivers/dma-buf/sw_sync.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index cb1bacb5a42b..fc52d837e579 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -120,7 +120,7 @@ static void dma_fence_array_release(struct dma_fence *fence) dma_fence_put(array->fences[i]); kfree(array->fences); - dma_fence_free(fence); + kfree(array); } const struct dma_fence_ops dma_fence_array_ops = { diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index 06f8ef97c6e8..b29e1f22f08e 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -203,7 +203,7 @@ static void dma_fence_chain_release(struct dma_fence *fence) dma_fence_put(prev); dma_fence_put(chain->fence); - dma_fence_free(fence); + kfree(chain); } const struct dma_fence_ops dma_fence_chain_ops = { diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c index 348b3a9170fa..80432eeb58c3 100644 --- a/drivers/dma-buf/sw_sync.c +++ b/drivers/dma-buf/sw_sync.c @@ -142,7 +142,7 @@ static void timeline_fence_release(struct dma_fence *fence) spin_unlock_irqrestore(fence->lock, flags); sync_timeline_put(parent); - dma_fence_free(fence); + kfree(pt); } static bool timeline_fence_signaled(struct dma_fence *fence) -- 2.17.1

3 years, 8 months

completely rework the dma_resv semantic

by Christian König

Hi Daniel, just a gentle ping that you wanted to take a look at this. Not much changed compared to the last version, only a minor bugfix in the dma_resv_get_singleton error handling. Regards, Christian.

3 years, 8 months

Re: [Linaro-mm-sig] [PATCH 18/24] dma-buf: add enum dma_resv_usage v3

by Daniel Vetter

On Tue, Dec 07, 2021 at 01:34:05PM +0100, Christian König wrote: > This change adds the dma_resv_usage enum and allows us to specify why a > dma_resv object is queried for its containing fences. > > Additional to that a dma_resv_usage_rw() helper function is added to aid > retrieving the fences for a read or write userspace submission. > > This is then deployed to the different query functions of the dma_resv > object and all of their users. When the write paratermer was previously > true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise. > > v2: add KERNEL/OTHER in separate patch > v3: some kerneldoc suggestions by Daniel > > Signed-off-by: Christian König <christian.koenig(a)amd.com> Just commenting on the kerneldoc here. > diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h > index 40ac9d486f8f..d96d8ca9af56 100644 > --- a/include/linux/dma-resv.h > +++ b/include/linux/dma-resv.h > @@ -49,6 +49,49 @@ extern struct ww_class reservation_ww_class; > > struct dma_resv_list; > > +/** > + * enum dma_resv_usage - how the fences from a dma_resv obj are used > + * > + * This enum describes the different use cases for a dma_resv object and > + * controls which fences are returned when queried. We need to link here to both dma_buf.resv and from there to here. Also we had a fair amount of text in the old dma_resv fields which should probably be included here. > + */ > +enum dma_resv_usage { > + /** > + * @DMA_RESV_USAGE_WRITE: Implicit write synchronization. > + * > + * This should only be used for userspace command submissions which add > + * an implicit write dependency. > + */ > + DMA_RESV_USAGE_WRITE, > + > + /** > + * @DMA_RESV_USAGE_READ: Implicit read synchronization. > + * > + * This should only be used for userspace command submissions which add > + * an implicit read dependency. I think the above would benefit from at least a link each to &dma_buf.resv for further discusion. Plus the READ flag needs a huge warning that in general it does _not_ guarantee that neither there's no writes possible, nor that the writes can be assumed mistakes and dropped (on buffer moves e.g.). Drivers can only make further assumptions for driver-internal dma_resv objects (e.g. on vm/pagetables) or when the fences are all fences of the same driver (e.g. the special sync rules amd has that takes the fence owner into account). We have this documented in the dma_buf.resv rules, but since it came up again in a discussion with Thomas H. somewhere, it's better to hammer this in a few more time. Specically in generally ignoring READ fences for buffer moves (well the copy job, memory freeing still has to wait for all of them) is a correctness bug. Maybe include a big warning that really the difference between READ and WRITE should only matter for implicit sync, and _not_ for anything else the kernel does. I'm assuming the actual replacement is all mechanical, so I skipped that one for now, that's for next year :-) -Daniel > + */ > + DMA_RESV_USAGE_READ, > +}; > + > +/** > + * dma_resv_usage_rw - helper for implicit sync > + * @write: true if we create a new implicit sync write > + * > + * This returns the implicit synchronization usage for write or read accesses, > + * see enum dma_resv_usage. > + */ > +static inline enum dma_resv_usage dma_resv_usage_rw(bool write) > +{ > + /* This looks confusing at first sight, but is indeed correct. > + * > + * The rational is that new write operations needs to wait for the > + * existing read and write operations to finish. > + * But a new read operation only needs to wait for the existing write > + * operations to finish. > + */ > + return write ? DMA_RESV_USAGE_READ : DMA_RESV_USAGE_WRITE; > +} > + > /** > * struct dma_resv - a reservation object manages fences for a buffer > * > @@ -147,8 +190,8 @@ struct dma_resv_iter { > /** @obj: The dma_resv object we iterate over */ > struct dma_resv *obj; > > - /** @all_fences: If all fences should be returned */ > - bool all_fences; > + /** @usage: Controls which fences are returned */ > + enum dma_resv_usage usage; > > /** @fence: the currently handled fence */ > struct dma_fence *fence; > @@ -178,14 +221,14 @@ struct dma_fence *dma_resv_iter_next(struct dma_resv_iter *cursor); > * dma_resv_iter_begin - initialize a dma_resv_iter object > * @cursor: The dma_resv_iter object to initialize > * @obj: The dma_resv object which we want to iterate over > - * @all_fences: If all fences should be returned or just the exclusive one > + * @usage: controls which fences to include, see enum dma_resv_usage. > */ > static inline void dma_resv_iter_begin(struct dma_resv_iter *cursor, > struct dma_resv *obj, > - bool all_fences) > + enum dma_resv_usage usage) > { > cursor->obj = obj; > - cursor->all_fences = all_fences; > + cursor->usage = usage; > cursor->fence = NULL; > } > > @@ -242,7 +285,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) > * dma_resv_for_each_fence - fence iterator > * @cursor: a struct dma_resv_iter pointer > * @obj: a dma_resv object pointer > - * @all_fences: true if all fences should be returned > + * @usage: controls which fences to return > * @fence: the current fence > * > * Iterate over the fences in a struct dma_resv object while holding the > @@ -251,8 +294,8 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) > * valid as long as the lock is held and so no extra reference to the fence is > * taken. > */ > -#define dma_resv_for_each_fence(cursor, obj, all_fences, fence) \ > - for (dma_resv_iter_begin(cursor, obj, all_fences), \ > +#define dma_resv_for_each_fence(cursor, obj, usage, fence) \ > + for (dma_resv_iter_begin(cursor, obj, usage), \ > fence = dma_resv_iter_first(cursor); fence; \ > fence = dma_resv_iter_next(cursor)) > > @@ -419,14 +462,14 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence); > void dma_resv_replace_fences(struct dma_resv *obj, uint64_t context, > struct dma_fence *fence); > void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence); > -int dma_resv_get_fences(struct dma_resv *obj, bool write, > +int dma_resv_get_fences(struct dma_resv *obj, enum dma_resv_usage usage, > unsigned int *num_fences, struct dma_fence ***fences); > -int dma_resv_get_singleton(struct dma_resv *obj, bool write, > +int dma_resv_get_singleton(struct dma_resv *obj, enum dma_resv_usage usage, > struct dma_fence **fence); > int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src); > -long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr, > - unsigned long timeout); > -bool dma_resv_test_signaled(struct dma_resv *obj, bool test_all); > +long dma_resv_wait_timeout(struct dma_resv *obj, enum dma_resv_usage usage, > + bool intr, unsigned long timeout); > +bool dma_resv_test_signaled(struct dma_resv *obj, enum dma_resv_usage usage); > void dma_resv_describe(struct dma_resv *obj, struct seq_file *seq); > > #endif /* _LINUX_RESERVATION_H */ > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 8 months

[PATCH] ASoC: qcom: Fix error code in lpass_platform_copy()

by Dan Carpenter

The copy_to/from_user() functions return the number of bytes remaining to be copied. This function needs to return negative error codes because snd_soc_pcm_component_copy_user() treats positive returns as success in soc_component_ret(). Fixes: 7d7209557b67 ("ASoC: qcom: Add support for codec dma driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- sound/soc/qcom/lpass-platform.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c index bf180a594c19..620312529c2f 100644 --- a/sound/soc/qcom/lpass-platform.c +++ b/sound/soc/qcom/lpass-platform.c @@ -1228,15 +1228,19 @@ static int lpass_platform_copy(struct snd_soc_component *component, channel * (rt->dma_bytes / rt->channels)); if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { - if (is_cdc_dma_port(dai_id)) + if (is_cdc_dma_port(dai_id)) { ret = copy_from_user_toio(dma_buf, buf, bytes); - else - ret = copy_from_user((void __force *)dma_buf, buf, bytes); + } else { + if (copy_from_user((void __force *)dma_buf, buf, bytes)) + ret = -EFAULT; + } } else if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { - if (is_cdc_dma_port(dai_id)) + if (is_cdc_dma_port(dai_id)) { ret = copy_to_user_fromio(buf, dma_buf, bytes); - else - ret = copy_to_user(buf, (void __force *)dma_buf, bytes); + } else { + if (copy_to_user(buf, (void __force *)dma_buf, bytes)) + ret = -EFAULT; + } } return ret; -- 2.20.1

3 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig