Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

5 participants
2541 discussions

Re: [Linaro-mm-sig] [RFC PATCH v2 2/2] RDMA/rxe: Add dma-buf support

by Daniel Vetter

On Fri, Oct 01, 2021 at 12:56:48PM +0900, Shunsuke Mie wrote: > 2021年9月30日(木) 23:41 Daniel Vetter <daniel(a)ffwll.ch>: > > > > On Wed, Sep 29, 2021 at 01:19:05PM +0900, Shunsuke Mie wrote: > > > Implement a ib device operation ‘reg_user_mr_dmabuf’. Generate a > > > rxe_map from the memory space linked the passed dma-buf. > > > > > > Signed-off-by: Shunsuke Mie <mie(a)igel.co.jp> > > > --- > > > drivers/infiniband/sw/rxe/rxe_loc.h | 2 + > > > drivers/infiniband/sw/rxe/rxe_mr.c | 118 ++++++++++++++++++++++++++ > > > drivers/infiniband/sw/rxe/rxe_verbs.c | 34 ++++++++ > > > drivers/infiniband/sw/rxe/rxe_verbs.h | 2 + > > > 4 files changed, 156 insertions(+) > > > > > > diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h b/drivers/infiniband/sw/rxe/rxe_loc.h > > > index 1ca43b859d80..8bc19ea1a376 100644 > > > --- a/drivers/infiniband/sw/rxe/rxe_loc.h > > > +++ b/drivers/infiniband/sw/rxe/rxe_loc.h > > > @@ -75,6 +75,8 @@ u8 rxe_get_next_key(u32 last_key); > > > void rxe_mr_init_dma(struct rxe_pd *pd, int access, struct rxe_mr *mr); > > > int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64 length, u64 iova, > > > int access, struct rxe_mr *mr); > > > +int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64 length, > > > + u64 iova, int access, struct rxe_mr *mr); > > > int rxe_mr_init_fast(struct rxe_pd *pd, int max_pages, struct rxe_mr *mr); > > > int rxe_mr_copy(struct rxe_mr *mr, u64 iova, void *addr, int length, > > > enum rxe_mr_copy_dir dir); > > > diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c > > > index 53271df10e47..af6ef671c3a5 100644 > > > --- a/drivers/infiniband/sw/rxe/rxe_mr.c > > > +++ b/drivers/infiniband/sw/rxe/rxe_mr.c > > > @@ -4,6 +4,7 @@ > > > * Copyright (c) 2015 System Fabric Works, Inc. All rights reserved. > > > */ > > > > > > +#include <linux/dma-buf.h> > > > #include "rxe.h" > > > #include "rxe_loc.h" > > > > > > @@ -245,6 +246,120 @@ int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64 length, u64 iova, > > > return err; > > > } > > > > > > +static int rxe_map_dmabuf_mr(struct rxe_mr *mr, > > > + struct ib_umem_dmabuf *umem_dmabuf) > > > +{ > > > + struct rxe_map_set *set; > > > + struct rxe_phys_buf *buf = NULL; > > > + struct rxe_map **map; > > > + void *vaddr, *vaddr_end; > > > + int num_buf = 0; > > > + int err; > > > + size_t remain; > > > + > > > + mr->dmabuf_map = kzalloc(sizeof &mr->dmabuf_map, GFP_KERNEL); > > > > dmabuf_maps are just tagged pointers (and we could shrink them to actually > > just a tagged pointer if anyone cares about the overhead of the separate > > bool), allocating them seperately is overkill. > > I agree with you. However, I think it is needed to unmap by > dma_buf_vunmap(). If there is another simple way to unmap it. It is not > needed I think. What do you think about it? dma_buf_vunmap does not kfree the dma_buf_map argument, so that's no reason to allocate it separately. Or I'm confused. Also apologies, I'm way behind on mails. -Daniel > > > > + if (!mr->dmabuf_map) { > > > + err = -ENOMEM; > > > + goto err_out; > > > + } > > > + > > > + err = dma_buf_vmap(umem_dmabuf->dmabuf, mr->dmabuf_map); > > > + if (err) > > > + goto err_free_dmabuf_map; > > > + > > > + set = mr->cur_map_set; > > > + set->page_shift = PAGE_SHIFT; > > > + set->page_mask = PAGE_SIZE - 1; > > > + > > > + map = set->map; > > > + buf = map[0]->buf; > > > + > > > + vaddr = mr->dmabuf_map->vaddr; > > > > dma_buf_map can be an __iomem too, you shouldn't dig around in this, but > > use the dma-buf-map.h helpers instead. On x86 (and I think also on most > > arm) it doesn't matter, but it's kinda not very nice in a pure software > > driver. > > > > If anything is missing in dma-buf-map.h wrappers just add more. > > > > Or alternatively you need to fail the import if you can't handle __iomem. > > > > Aside from these I think the dma-buf side here for cpu access looks > > reasonable now. > > -Daniel > I'll see the dma-buf-map.h and consider the error handling that you suggested. > I appreciate your support. > > Thanks a lot, > Shunsuke. > > > > + vaddr_end = vaddr + umem_dmabuf->dmabuf->size; > > > + remain = umem_dmabuf->dmabuf->size; > > > + > > > + for (; remain; vaddr += PAGE_SIZE) { > > > + if (num_buf >= RXE_BUF_PER_MAP) { > > > + map++; > > > + buf = map[0]->buf; > > > + num_buf = 0; > > > + } > > > + > > > + buf->addr = (uintptr_t)vaddr; > > > + if (remain >= PAGE_SIZE) > > > + buf->size = PAGE_SIZE; > > > + else > > > + buf->size = remain; > > > + remain -= buf->size; > > > + > > > + num_buf++; > > > + buf++; > > > + } > > > + > > > + return 0; > > > + > > > +err_free_dmabuf_map: > > > + kfree(mr->dmabuf_map); > > > +err_out: > > > + return err; > > > +} > > > + > > > +static void rxe_unmap_dmabuf_mr(struct rxe_mr *mr) > > > +{ > > > + struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(mr->umem); > > > + > > > + dma_buf_vunmap(umem_dmabuf->dmabuf, mr->dmabuf_map); > > > + kfree(mr->dmabuf_map); > > > +} > > > + > > > +int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64 length, > > > + u64 iova, int access, struct rxe_mr *mr) > > > +{ > > > + struct ib_umem_dmabuf *umem_dmabuf; > > > + struct rxe_map_set *set; > > > + int err; > > > + > > > + umem_dmabuf = ib_umem_dmabuf_get(pd->ibpd.device, start, length, fd, > > > + access, NULL); > > > + if (IS_ERR(umem_dmabuf)) { > > > + err = PTR_ERR(umem_dmabuf); > > > + goto err_out; > > > + } > > > + > > > + rxe_mr_init(access, mr); > > > + > > > + err = rxe_mr_alloc(mr, ib_umem_num_pages(&umem_dmabuf->umem), 0); > > > + if (err) { > > > + pr_warn("%s: Unable to allocate memory for map\n", __func__); > > > + goto err_release_umem; > > > + } > > > + > > > + mr->ibmr.pd = &pd->ibpd; > > > + mr->umem = &umem_dmabuf->umem; > > > + mr->access = access; > > > + mr->state = RXE_MR_STATE_VALID; > > > + mr->type = IB_MR_TYPE_USER; > > > + > > > + set = mr->cur_map_set; > > > + set->length = length; > > > + set->iova = iova; > > > + set->va = start; > > > + set->offset = ib_umem_offset(mr->umem); > > > + > > > + err = rxe_map_dmabuf_mr(mr, umem_dmabuf); > > > + if (err) > > > + goto err_free_map_set; > > > + > > > + return 0; > > > + > > > +err_free_map_set: > > > + rxe_mr_free_map_set(mr->num_map, mr->cur_map_set); > > > +err_release_umem: > > > + ib_umem_release(&umem_dmabuf->umem); > > > +err_out: > > > + return err; > > > +} > > > + > > > int rxe_mr_init_fast(struct rxe_pd *pd, int max_pages, struct rxe_mr *mr) > > > { > > > int err; > > > @@ -703,6 +818,9 @@ void rxe_mr_cleanup(struct rxe_pool_entry *arg) > > > { > > > struct rxe_mr *mr = container_of(arg, typeof(*mr), pelem); > > > > > > + if (mr->umem && mr->umem->is_dmabuf) > > > + rxe_unmap_dmabuf_mr(mr); > > > + > > > ib_umem_release(mr->umem); > > > > > > if (mr->cur_map_set) > > > diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c b/drivers/infiniband/sw/rxe/rxe_verbs.c > > > index 9d0bb9aa7514..6191bb4f434d 100644 > > > --- a/drivers/infiniband/sw/rxe/rxe_verbs.c > > > +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c > > > @@ -916,6 +916,39 @@ static struct ib_mr *rxe_reg_user_mr(struct ib_pd *ibpd, > > > return ERR_PTR(err); > > > } > > > > > > +static struct ib_mr *rxe_reg_user_mr_dmabuf(struct ib_pd *ibpd, u64 start, > > > + u64 length, u64 iova, int fd, > > > + int access, struct ib_udata *udata) > > > +{ > > > + int err; > > > + struct rxe_dev *rxe = to_rdev(ibpd->device); > > > + struct rxe_pd *pd = to_rpd(ibpd); > > > + struct rxe_mr *mr; > > > + > > > + mr = rxe_alloc(&rxe->mr_pool); > > > + if (!mr) { > > > + err = -ENOMEM; > > > + goto err2; > > > + } > > > + > > > + rxe_add_index(mr); > > > + > > > + rxe_add_ref(pd); > > > + > > > + err = rxe_mr_dmabuf_init_user(pd, fd, start, length, iova, access, mr); > > > + if (err) > > > + goto err3; > > > + > > > + return &mr->ibmr; > > > + > > > +err3: > > > + rxe_drop_ref(pd); > > > + rxe_drop_index(mr); > > > + rxe_drop_ref(mr); > > > +err2: > > > + return ERR_PTR(err); > > > +} > > > + > > > static struct ib_mr *rxe_alloc_mr(struct ib_pd *ibpd, enum ib_mr_type mr_type, > > > u32 max_num_sg) > > > { > > > @@ -1081,6 +1114,7 @@ static const struct ib_device_ops rxe_dev_ops = { > > > .query_qp = rxe_query_qp, > > > .query_srq = rxe_query_srq, > > > .reg_user_mr = rxe_reg_user_mr, > > > + .reg_user_mr_dmabuf = rxe_reg_user_mr_dmabuf, > > > .req_notify_cq = rxe_req_notify_cq, > > > .resize_cq = rxe_resize_cq, > > > > > > diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.h b/drivers/infiniband/sw/rxe/rxe_verbs.h > > > index c807639435eb..0aa95ab06b6e 100644 > > > --- a/drivers/infiniband/sw/rxe/rxe_verbs.h > > > +++ b/drivers/infiniband/sw/rxe/rxe_verbs.h > > > @@ -334,6 +334,8 @@ struct rxe_mr { > > > > > > struct rxe_map_set *cur_map_set; > > > struct rxe_map_set *next_map_set; > > > + > > > + struct dma_buf_map *dmabuf_map; > > > }; > > > > > > enum rxe_mw_state { > > > -- > > > 2.17.1 > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 years, 3 months

[PATCH] dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion

by Tvrtko Ursulin

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cache the count of shared fences in the iterator to avoid dereferencing the dma_resv_object outside the RCU protection. Otherwise iterator and its users can observe an incosistent state which makes it impossible to use safely. Such as: <6> [187.517041] [IGT] gem_sync: executing <7> [187.536343] i915 0000:00:02.0: [drm:i915_gem_context_create_ioctl [i915]] HW context 1 created <7> [187.536793] i915 0000:00:02.0: [drm:i915_gem_context_create_ioctl [i915]] HW context 1 created <6> [187.551235] [IGT] gem_sync: starting subtest basic-many-each <1> [188.935462] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [188.935485] #PF: supervisor write access in kernel mode <1> [188.935495] #PF: error_code(0x0002) - not-present page <6> [188.935504] PGD 0 P4D 0 <4> [188.935512] Oops: 0002 [#1] PREEMPT SMP NOPTI <4> [188.935521] CPU: 2 PID: 1467 Comm: gem_sync Not tainted 5.15.0-rc4-CI-Patchwork_21264+ #1 <4> [188.935535] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018 <4> [188.935546] RIP: 0010:dma_resv_get_fences+0x116/0x2d0 <4> [188.935560] Code: 10 85 c0 7f c9 be 03 00 00 00 e8 15 8b df ff eb bd e8 8e c6 ff ff eb b6 41 8b 04 24 49 8b 55 00 48 89 e7 8d 48 01 41 89 0c 24 <4c> 89 34 c2 e8 41 f2 ff ff 49 89 c6 48 85 c0 75 8c 48 8b 44 24 10 <4> [188.935583] RSP: 0018:ffffc900011dbcc8 EFLAGS: 00010202 <4> [188.935593] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 0000000000000001 <4> [188.935603] RDX: 0000000000000010 RSI: ffffffff822e343c RDI: ffffc900011dbcc8 <4> [188.935613] RBP: ffffc900011dbd48 R08: ffff88812d255bb8 R09: 00000000fffffffe <4> [188.935623] R10: 0000000000000001 R11: 0000000000000000 R12: ffffc900011dbd44 <4> [188.935633] R13: ffffc900011dbd50 R14: ffff888113d29cc0 R15: 0000000000000000 <4> [188.935643] FS: 00007f68d17e9700(0000) GS:ffff888277900000(0000) knlGS:0000000000000000 <4> [188.935655] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [188.935665] CR2: 0000000000000010 CR3: 000000012d0a4000 CR4: 00000000003506e0 <4> [188.935676] Call Trace: <4> [188.935685] i915_gem_object_wait+0x1ff/0x410 [i915] <4> [188.935988] i915_gem_wait_ioctl+0xf2/0x2a0 [i915] <4> [188.936272] ? i915_gem_object_wait+0x410/0x410 [i915] <4> [188.936533] drm_ioctl_kernel+0xae/0x140 <4> [188.936546] drm_ioctl+0x201/0x3d0 <4> [188.936555] ? i915_gem_object_wait+0x410/0x410 [i915] <4> [188.936820] ? __fget_files+0xc2/0x1c0 <4> [188.936830] ? __fget_files+0xda/0x1c0 <4> [188.936839] __x64_sys_ioctl+0x6d/0xa0 <4> [188.936848] do_syscall_64+0x3a/0xb0 <4> [188.936859] entry_SYSCALL_64_after_hwframe+0x44/0xae If the shared object has changed during the RCU unlocked period callers will correctly handle the restart on the next iteration. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Fixes: 96601e8a4755 ("dma-buf: use new iterator in dma_resv_copy_fences") Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4274 Cc: Christian König <christian.koenig(a)amd.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-resv.c | 18 ++++++++++-------- include/linux/dma-resv.h | 5 ++++- 2 files changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index a480af9581bd..7b6d881c8904 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -333,10 +333,14 @@ static void dma_resv_iter_restart_unlocked(struct dma_resv_iter *cursor) { cursor->seq = read_seqcount_begin(&cursor->obj->seq); cursor->index = -1; - if (cursor->all_fences) + cursor->shared_count = 0; + if (cursor->all_fences) { cursor->fences = dma_resv_shared_list(cursor->obj); - else + if (cursor->fences) + cursor->shared_count = cursor->fences->shared_count; + } else { cursor->fences = NULL; + } cursor->is_restarted = true; } @@ -363,7 +367,7 @@ static void dma_resv_iter_walk_unlocked(struct dma_resv_iter *cursor) continue; } else if (!cursor->fences || - cursor->index >= cursor->fences->shared_count) { + cursor->index >= cursor->shared_count) { cursor->fence = NULL; break; @@ -448,10 +452,8 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv *src) dma_resv_list_free(list); dma_fence_put(excl); - if (cursor.fences) { - unsigned int cnt = cursor.fences->shared_count; - - list = dma_resv_list_alloc(cnt); + if (cursor.shared_count) { + list = dma_resv_list_alloc(cursor.shared_count); if (!list) { dma_resv_iter_end(&cursor); return -ENOMEM; @@ -522,7 +524,7 @@ int dma_resv_get_fences(struct dma_resv *obj, struct dma_fence **fence_excl, if (fence_excl) dma_fence_put(*fence_excl); - count = cursor.fences ? cursor.fences->shared_count : 0; + count = cursor.shared_count; count += fence_excl ? 0 : 1; /* Eventually re-allocate the array */ diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index 8b6c20636a79..3e1bff147428 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -170,9 +170,12 @@ struct dma_resv_iter { /** @index: index into the shared fences */ unsigned int index; - /** @fences: the shared fences */ + /** @fences: the shared fences; private, *MUST* not dereference */ struct dma_resv_list *fences; + /** @shared_count: number of shared fences */ + unsigned int shared_count; + /** @is_restarted: true if this is the first returned fence */ bool is_restarted; }; -- 2.30.2

3 years, 3 months

Re: [Linaro-mm-sig] [PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

by Christian König

Am 09.10.21 um 07:55 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > If dma-buf don't want userspace users to touch the dmabuf buffer, > it seems we should add this restriction into dma_buf_ops.mmap, > not in this IOCTL:DMA_BUF_SET_NAME. > > With this restriction, we can only know the kernel users of the dmabuf > by attachments. > However, for many userspace users, such as userpsace users of dma_heap, > they also need to mark the usage of dma-buf, and they don't care about > who attached to this dmabuf, and seems it's no meaning to be waiting for > IOCTL:DMA_BUF_SET_NAME rather than mmap. Sounds valid to me, but I have no idea why this restriction was added in the first place. Can you double check the git history and maybe identify when that was added? Mentioning this change in the commit message then might make things a bit easier to understand. Thanks, Christian. > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> > --- > drivers/dma-buf/dma-buf.c | 14 ++------------ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 511fe0d217a0..db2f4efdec32 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > > /** > * dma_buf_set_name - Set a name to a specific dma_buf to track the usage. > - * The name of the dma-buf buffer can only be set when the dma-buf is not > - * attached to any devices. It could theoritically support changing the > - * name of the dma-buf if the same piece of memory is used for multiple > - * purpose between different devices. > + * It could theoretically support changing the 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 > @@ -346,19 +344,11 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) > if (IS_ERR(name)) > return PTR_ERR(name); > > - dma_resv_lock(dmabuf->resv, NULL); > - if (!list_empty(&dmabuf->attachments)) { > - ret = -EBUSY; > - kfree(name); > - goto out_unlock; > - } > spin_lock(&dmabuf->name_lock); > kfree(dmabuf->name); > dmabuf->name = name; > spin_unlock(&dmabuf->name_lock); > > -out_unlock: > - dma_resv_unlock(dmabuf->resv); > return ret; > } >

3 years, 3 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

by Randy Dunlap

On 10/8/21 7:47 PM, guangming.cao(a)mediatek.com wrote: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > If dma-buf don't want userspace users to touch the dmabuf buffer, > it seems we should add this restriction into dma_buf_ops.mmap, > not in this IOCTL:DMA_BUF_SET_NAME. > > With this restriction, we can only know the kernel users of the dmabuf > by attachments. > However, for many userspace users, such as userpsace users of dma_heap, > they also need to mark the usage of dma-buf, and they don't care about > who attached to this dmabuf, and seems it's no meaning to waitting for to be waiting for > IOCTL:DMA_BUF_SET_NAME rather than mmap. > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> > --- > drivers/dma-buf/dma-buf.c | 14 ++------------ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 511fe0d217a0..afbd0a226639 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) > > /** > * dma_buf_set_name - Set a name to a specific dma_buf to track the usage. > - * The name of the dma-buf buffer can only be set when the dma-buf is not > - * attached to any devices. It could theoritically support changing the > - * name of the dma-buf if the same piece of memory is used for multiple > - * purpose between different devices. > + * It could theoritically support changing the name of the dma-buf if the same theoretically (yes, it was incorrect before this change.) > + * 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 > @@ -346,19 +344,11 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf) > if (IS_ERR(name)) > return PTR_ERR(name); > > - dma_resv_lock(dmabuf->resv, NULL); > - if (!list_empty(&dmabuf->attachments)) { > - ret = -EBUSY; > - kfree(name); > - goto out_unlock; > - } > spin_lock(&dmabuf->name_lock); > kfree(dmabuf->name); > dmabuf->name = name; > spin_unlock(&dmabuf->name_lock); > > -out_unlock: > - dma_resv_unlock(dmabuf->resv); > return ret; > } > > -- ~Randy

3 years, 3 months

Re: [Linaro-mm-sig] [PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name

by Christian König

Am 08.10.21 um 09:54 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > Because dma-buf.name can be freed in func: "dma_buf_set_name", > so, we need to acquire lock first before we read/write dma_buf.name > to prevent Use After Free(UAF) issue. > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Going to push that upstream if nobody else objects. Thanks, Christian. > --- > drivers/dma-buf/dma-buf.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 511fe0d217a0..a7f6fd13a635 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1372,6 +1372,8 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) > if (ret) > goto error_unlock; > > + > + spin_lock(&buf_obj->name_lock); > seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n", > buf_obj->size, > buf_obj->file->f_flags, buf_obj->file->f_mode, > @@ -1379,6 +1381,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) > buf_obj->exp_name, > file_inode(buf_obj->file)->i_ino, > buf_obj->name ?: ""); > + spin_unlock(&buf_obj->name_lock); > > robj = buf_obj->resv; > fence = dma_resv_excl_fence(robj);

3 years, 3 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: acquire name lock before read/write dma_buf.name

by Christian König

Am 08.10.21 um 08:29 schrieb guangming.cao(a)mediatek.com: > From: Guangming Cao <Guangming.Cao(a)mediatek.com> > > Because dma-buf.name can be freed in func: "dma_buf_set_name", > so, we need to acquire lock first before we read/write dma_buf.name > to prevent Use After Free(UAF) issue. > > Signed-off-by: Guangming Cao <Guangming.Cao(a)mediatek.com> > --- > drivers/dma-buf/dma-buf.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 511fe0d217a0..aebb51b3ff52 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -80,7 +80,9 @@ static void dma_buf_release(struct dentry *dentry) > dma_resv_fini(dmabuf->resv); > > module_put(dmabuf->owner); > + spin_lock(&dmabuf->name_lock); > kfree(dmabuf->name); > + spin_unlock(&dmabuf->name_lock); That here is certainly a NAK. This is the release function if somebody is changing the name on a released DMA-buf we have much bigger problems. > kfree(dmabuf); > } > > @@ -1372,6 +1374,8 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) > if (ret) > goto error_unlock; > > + > + spin_lock(&dmabuf->name_lock); > seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n", > buf_obj->size, > buf_obj->file->f_flags, buf_obj->file->f_mode, > @@ -1379,6 +1383,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) > buf_obj->exp_name, > file_inode(buf_obj->file)->i_ino, > buf_obj->name ?: ""); > + spin_unlock(&dmabuf->name_lock); Yeah, that part looks like a good idea to me as well. Christian. > > robj = buf_obj->resv; > fence = dma_resv_excl_fence(robj);

3 years, 3 months

[PATCH 1/2] dma-buf: add dma_resv_for_each_fence v3

by Christian König

A simpler version of the iterator to be used when the dma_resv object is locked. v2: fix index check here as well v3: minor coding improvement, some documentation cleanup Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-resv.c | 51 ++++++++++++++++++++++++++++++++++++++ include/linux/dma-resv.h | 20 +++++++++++++++ 2 files changed, 71 insertions(+) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index a480af9581bd..2f98caa68ae5 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -423,6 +423,57 @@ struct dma_fence *dma_resv_iter_next_unlocked(struct dma_resv_iter *cursor) } EXPORT_SYMBOL(dma_resv_iter_next_unlocked); +/** + * dma_resv_iter_first - first fence from a locked dma_resv object + * @cursor: cursor to record the current position + * + * Return the first fence in the dma_resv object while holding the + * &dma_resv.lock. + */ +struct dma_fence *dma_resv_iter_first(struct dma_resv_iter *cursor) +{ + struct dma_fence *fence; + + dma_resv_assert_held(cursor->obj); + + cursor->index = 0; + if (cursor->all_fences) + cursor->fences = dma_resv_shared_list(cursor->obj); + else + cursor->fences = NULL; + + fence = dma_resv_excl_fence(cursor->obj); + if (!fence) + fence = dma_resv_iter_next(cursor); + + cursor->is_restarted = true; + return fence; +} +EXPORT_SYMBOL_GPL(dma_resv_iter_first); + +/** + * dma_resv_iter_next - next fence from a locked dma_resv object + * @cursor: cursor to record the current position + * + * Return the next fences from the dma_resv object while holding the + * &dma_resv.lock. + */ +struct dma_fence *dma_resv_iter_next(struct dma_resv_iter *cursor) +{ + unsigned int idx; + + dma_resv_assert_held(cursor->obj); + + cursor->is_restarted = false; + if (!cursor->fences || cursor->index >= cursor->fences->shared_count) + return NULL; + + idx = cursor->index++; + return rcu_dereference_protected(cursor->fences->shared[idx], + dma_resv_held(cursor->obj)); +} +EXPORT_SYMBOL_GPL(dma_resv_iter_next); + /** * dma_resv_copy_fences - Copy all fences from src to dst. * @dst: the destination reservation object diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index 764138ad8583..491359cea54c 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -179,6 +179,8 @@ struct dma_resv_iter { struct dma_fence *dma_resv_iter_first_unlocked(struct dma_resv_iter *cursor); struct dma_fence *dma_resv_iter_next_unlocked(struct dma_resv_iter *cursor); +struct dma_fence *dma_resv_iter_first(struct dma_resv_iter *cursor); +struct dma_fence *dma_resv_iter_next(struct dma_resv_iter *cursor); /** * dma_resv_iter_begin - initialize a dma_resv_iter object @@ -244,6 +246,24 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) for (fence = dma_resv_iter_first_unlocked(cursor); \ fence; fence = dma_resv_iter_next_unlocked(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 + * @fence: the current fence + * + * Iterate over the fences in a struct dma_resv object while holding the + * &dma_resv.lock. @all_fences controls if the shared fences are returned as + * well. The cursor initialisation is part of the iterator and the fence stays + * 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), \ + fence = dma_resv_iter_first(cursor); fence; \ + fence = dma_resv_iter_next(cursor)) + #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base) #define dma_resv_assert_held(obj) lockdep_assert_held(&(obj)->lock.base) -- 2.25.1

3 years, 3 months

Deploying new iterator interface for dma-buf

by Christian König

Hi guys, I've fixed up the lockdep splat in the new selftests found by the CI systems and added another path for dma_resv_poll. I know you guys are flooded, but can we get at least the first few patches committed? The patches to change the individual drivers could also be pushed later on I think. Thanks, Christian.

3 years, 3 months

Re: [Linaro-mm-sig] [PATCH net-next 2/5] dt-bindings: net: brcm, unimac-mdio: Add asp-v2.0

by Rob Herring

On Fri, 24 Sep 2021 14:44:48 -0700, Justin Chen wrote: > The ASP 2.0 Ethernet controller uses a brcm unimac. > > Signed-off-by: Justin Chen <justinpopo6(a)gmail.com> > Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> > --- > Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring <robh(a)kernel.org>

3 years, 3 months

Re: [Linaro-mm-sig] [PATCH v6 2/2] habanalabs: add support for dma-buf exporter

by Jason Gunthorpe

On Thu, Sep 30, 2021 at 03:46:35PM +0300, Oded Gabbay wrote: > After reading the kernel iommu code, I think this is not relevant > here, and I'll add a comment appropriately but I'll also write it > here, and please correct me if my understanding is wrong. > > The memory behind this specific dma-buf has *always* resided on the > device itself, i.e. it lives only in the 'device' domain (after all, > it maps a PCI bar address which points to the device memory). > Therefore, it was never in the 'CPU' domain and hence, there is no > need to perform a sync of the memory to the CPU's cache, as it was > never inside that cache to begin with. > > This is not the same case as with regular memory which is dma-mapped > and then copied into the device using a dma engine. In that case, > the memory started in the 'CPU' domain and moved to the 'device' > domain. When it is unmapped it will indeed be recycled to be used > for another purpose and therefore we need to sync the CPU cache. > > Is my understanding correct ? It makes sense to me Jason

3 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig