Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

3 participants
2908 discussions

Re: [Linaro-mm-sig] [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

by Christian König

Am 11.03.20 um 15:38 schrieb Jason Gunthorpe: > On Wed, Mar 11, 2020 at 03:33:01PM +0100, Christian König wrote: >> Am 11.03.20 um 15:04 schrieb Jason Gunthorpe: >>> On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote: >>>> Check if we can do peer2peer on the PCIe bus. >>>> >>>> Signed-off-by: Christian König <christian.koenig(a)amd.com> >>>> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >>>> index aef12ee2f1e3..bbf67800c8a6 100644 >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >>>> @@ -38,6 +38,7 @@ >>>> #include <drm/amdgpu_drm.h> >>>> #include <linux/dma-buf.h> >>>> #include <linux/dma-fence-array.h> >>>> +#include <linux/pci-p2pdma.h> >>>> /** >>>> * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation >>>> @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf, >>>> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); >>>> int r; >>>> + if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0) >>>> + attach->peer2peer = false; >>>> + >>> Are there other related patches than this series? >>> >>> p2p dma mapping needs to be done in common code, in p2pdma.c - ie this >>> open coding is missing the bus_offset stuff, at least. >> Yeah, I'm aware of this. But I couldn't find a better way for now. > Well, it isn't optional :) > >>> I really do not want to see drivers open code this stuff. >>> >>> We already have a p2pdma API for handling the struct page case, so I >>> suggest adding some new p2pdma API to handle this for non-struct page >>> cases. >>> >>> ie some thing like: >>> >>> int 'p2pdma map bar'( >>> struct pci_device *source, >>> unsigned int source_bar_number, >>> struct pci_device *dest, >>> physaddr&len *array_of_offsets & length pairs into source bar, >>> struct scatterlist *output_sgl) >> Well that's exactly what I have to avoid since I don't have the array of >> offsets around and want to avoid constructing it. > Maybe it doesn't need an array of offsets - just a single offset and > callers can iterate the API? Yes, that would of course work as well. But I was assuming that p2pdma_map_bar() needs some state between those calls. > >> Similar problem for dma_map_resource(). My example does this on demand, but >> essentially we also have use cases where this is done only once. > I'm not sure if this is portable. Does any IOMMU HW need to know P2P > is happening to setup successfully? We currently support such a narrow > scope of HW for P2P.. On the AMD hardware I'm testing this calling dma_map_resource() already seems to work with IOMMU enabled. (Well at least it seemed so 6month ago when I last tested this). >> Ideally we would have some function to create an sgl based on some arbitrary >> collection of offsets and length inside a BAR. > Isn't that what I just proposed above ? Yes, just didn't thought that this would easily possible. I will double check the p2pdma code again. Thanks, Christian. > > Jason

5 years, 3 months

Re: [Linaro-mm-sig] [PATCH 4/6] drm/amdgpu: add checks if DMA-buf P2P is supported

by Christian König

Am 11.03.20 um 15:04 schrieb Jason Gunthorpe: > On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote: >> Check if we can do peer2peer on the PCIe bus. >> >> Signed-off-by: Christian König <christian.koenig(a)amd.com> >> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >> index aef12ee2f1e3..bbf67800c8a6 100644 >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c >> @@ -38,6 +38,7 @@ >> #include <drm/amdgpu_drm.h> >> #include <linux/dma-buf.h> >> #include <linux/dma-fence-array.h> >> +#include <linux/pci-p2pdma.h> >> >> /** >> * amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation >> @@ -179,6 +180,9 @@ static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf, >> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); >> int r; >> >> + if (pci_p2pdma_distance_many(adev->pdev, &attach->dev, 1, true) < 0) >> + attach->peer2peer = false; >> + > Are there other related patches than this series? > > p2p dma mapping needs to be done in common code, in p2pdma.c - ie this > open coding is missing the bus_offset stuff, at least. Yeah, I'm aware of this. But I couldn't find a better way for now. > I really do not want to see drivers open code this stuff. > > We already have a p2pdma API for handling the struct page case, so I > suggest adding some new p2pdma API to handle this for non-struct page > cases. > > ie some thing like: > > int 'p2pdma map bar'( > struct pci_device *source, > unsigned int source_bar_number, > struct pci_device *dest, > physaddr&len *array_of_offsets & length pairs into source bar, > struct scatterlist *output_sgl) Well that's exactly what I have to avoid since I don't have the array of offsets around and want to avoid constructing it. Similar problem for dma_map_resource(). My example does this on demand, but essentially we also have use cases where this is done only once. Ideally we would have some function to create an sgl based on some arbitrary collection of offsets and length inside a BAR. Regards, Christian. > > Jason

5 years, 3 months

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

by Christian König

Am 26.02.20 um 17:46 schrieb Bas Nieuwenhuizen: > On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand <jason(a)jlekstrand.net> wrote: >> On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter <daniel(a)ffwll.ch> wrote: >>> On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote: >>> [SNIP] >>>> Just imagine that you access some DMA-buf with a shader and that operation >>>> is presented as a fence on the DMA-bufs reservation object. And now you can >>>> go ahead and replace that fence and free up the memory. >>>> >>>> Tricking the Linux kernel into allocating page tables in that freed memory >>>> is trivial and that's basically it you can overwrite page tables with your >>>> shader and gain access to all of system memory :) >>>> >>>> What we could do is to always make sure that the added fences will complete >>>> later than the already existing ones, but that is also rather tricky to get >>>> right. I wouldn't do that if we don't have a rather big use case for this. >> Right. I thought about that but I'm still learning how dma_resv >> works. It'd be easy enough to make a fence array that contains both >> the old fence and the new fence and replace the old fence with that. >> What I don't know is the proper way to replace the exclusive fence >> safely. Some sort of atomic_cpxchg loop, perhaps? I presume there's >> some way of doing it properly because DRM drivers are doing it all the >> time. First of all you need to grab the lock of the dma_resv object or you can't replace the exclusive nor the shared ones. This way you don't need to do a atomic_cmpxchg or anything else and still guarantee correct ordering. > I think for an exclusive fence you may need to create a fence array > that includes the existing exclusive and shared fences in the dma_resv > combined with the added fence. Yes, that at least gives us the correct synchronization. > However, I'm not sure what the best way is to do garbage collection on > that so that we don't get an impossibly list of fence arrays. Exactly yes. That's also the reason why the dma_fence_chain container I came up with for the sync timeline stuff has such a rather sophisticated garbage collection. When some of the included fences signal you need to free up the array/chain and make sure that the memory for the container can be reused. > (Note > the dma_resv has a lock that needs to be taken before adding an > exclusive fence, might be useful). Some code that does a thing like > this is __dma_resv_make_exclusive in > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c Wanted to move that into dma_resv.c for quite a while since there are quite a few other cases where we need this. Regards, Christian. > The other piece of the puzzle is that on the submit path this would > need something to ignore implicit fences. And there semantically the > question comes up whether it is safe for a driver to ignore exclusive > fences from another driver. (and then we have amdgpu which has its own > rules on exclusiveness of its shared fences based on the context. e.g. > the current option to ignore implicit fences for a buffer still syncs > on exclusive fences on the buffer).

5 years, 3 months

Re: [Linaro-mm-sig] KASAN: use-after-free Read in dmabuffs_dname

by Hillf Danton

On Fri, 06 Mar 2020 21:41:13 -0800 > syzbot found the following crash on: > > HEAD commit: 63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=11653ac3e00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=9833e26bab355358 > dashboard link: https://syzkaller.appspot.com/bug?extid=3643a18836bce555bff6 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > userspace arch: i386 > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+3643a18836bce555bff6(a)syzkaller.appspotmail.com > > ================================================================== > BUG: KASAN: use-after-free in dmabuffs_dname+0x4f4/0x560 drivers/dma-buf/dma-buf.c:48 > Read of size 8 at addr ffff8880a6b390e8 by task syz-executor.1/2394 > > CPU: 1 PID: 2394 Comm: syz-executor.1 Not tainted 5.6.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x197/0x210 lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 > __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506 > kasan_report+0x12/0x20 mm/kasan/common.c:641 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 > dmabuffs_dname+0x4f4/0x560 drivers/dma-buf/dma-buf.c:48 > tomoyo_realpath_from_path+0x165/0x660 security/tomoyo/realpath.c:259 > tomoyo_get_realpath security/tomoyo/file.c:151 [inline] > tomoyo_check_open_permission+0x2a3/0x3e0 security/tomoyo/file.c:771 > tomoyo_file_open security/tomoyo/tomoyo.c:319 [inline] > tomoyo_file_open+0xa9/0xd0 security/tomoyo/tomoyo.c:314 > security_file_open+0x71/0x300 security/security.c:1529 > do_dentry_open+0x37a/0x1380 fs/open.c:784 > vfs_open+0xa0/0xd0 fs/open.c:914 > do_last fs/namei.c:3490 [inline] > path_openat+0x12ee/0x3490 fs/namei.c:3607 > do_filp_open+0x192/0x260 fs/namei.c:3637 > do_sys_openat2+0x5eb/0x7e0 fs/open.c:1149 > do_sys_open+0xf2/0x180 fs/open.c:1165 > __do_compat_sys_open fs/open.c:1212 [inline] > __se_compat_sys_open fs/open.c:1210 [inline] > __ia32_compat_sys_open+0x79/0xb0 fs/open.c:1210 > do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] > do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > RIP: 0023:0xf7fd8e39 > Code: 1d 00 00 00 89 d3 5b 5e 5d c3 8b 04 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 > RSP: 002b:00000000f5db2014 EFLAGS: 00000296 ORIG_RAX: 0000000000000005 > RAX: ffffffffffffffda RBX: 00000000f5db204c RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000c09 RDI: 00000000f5db204c > RBP: 00000000f5db2168 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 > > Allocated by task 2388: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > __kasan_kmalloc mm/kasan/common.c:515 [inline] > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:488 > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 > __do_kmalloc mm/slab.c:3656 [inline] > __kmalloc+0x163/0x770 mm/slab.c:3665 > kmalloc include/linux/slab.h:560 [inline] > kzalloc include/linux/slab.h:669 [inline] > dma_buf_export+0x24d/0xa80 drivers/dma-buf/dma-buf.c:533 > ion_alloc drivers/staging/android/ion/ion.c:386 [inline] > ion_ioctl+0x5a9/0xd20 drivers/staging/android/ion/ion.c:495 > compat_ptr_ioctl+0x6e/0xa0 fs/ioctl.c:804 > __do_compat_sys_ioctl fs/ioctl.c:857 [inline] > __se_compat_sys_ioctl fs/ioctl.c:808 [inline] > __ia32_compat_sys_ioctl+0x245/0x2c0 fs/ioctl.c:808 > do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] > do_fast_syscall_32+0x27b/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > > Freed by task 2380: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > kasan_set_free_info mm/kasan/common.c:337 [inline] > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:476 > kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 > __cache_free mm/slab.c:3426 [inline] > kfree+0x10a/0x2c0 mm/slab.c:3757 > dma_buf_release+0x343/0x420 drivers/dma-buf/dma-buf.c:111 > __fput+0x2ff/0x890 fs/file_table.c:280 > ____fput+0x16/0x20 fs/file_table.c:313 > task_work_run+0x145/0x1c0 kernel/task_work.c:113 > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:164 > prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline] > syscall_return_slowpath arch/x86/entry/common.c:278 [inline] > do_syscall_32_irqs_on arch/x86/entry/common.c:352 [inline] > do_fast_syscall_32+0xbbd/0xe16 arch/x86/entry/common.c:408 > entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 > > The buggy address belongs to the object at ffff8880a6b39000 > which belongs to the cache kmalloc-1k of size 1024 > The buggy address is located 232 bytes inside of > 1024-byte region [ffff8880a6b39000, ffff8880a6b39400) > The buggy address belongs to the page: > page:ffffea00029ace40 refcount:1 mapcount:0 mapping:ffff8880aa400c40 index:0x0 > flags: 0xfffe0000000200(slab) > raw: 00fffe0000000200 ffffea0002346b48 ffffea00022f49c8 ffff8880aa400c40 > raw: 0000000000000000 ffff8880a6b39000 0000000100000002 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff8880a6b38f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff8880a6b39000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > >ffff8880a6b39080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff8880a6b39100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff8880a6b39180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== Add a completion for dmabuf releaser to wait those who are either holding the resv lock or aquiring it. --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -334,6 +334,9 @@ struct dma_buf { __poll_t active; } cb_excl, cb_shared; + + atomic_t resv_user; + struct completion done; }; /** --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -45,11 +45,20 @@ static char *dmabuffs_dname(struct dentr size_t ret = 0; dmabuf = dentry->d_fsdata; + if (!dmabuf) + goto print_name; + + atomic_inc(&dmabuf->resv_user); + dma_resv_lock(dmabuf->resv, NULL); if (dmabuf->name) ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); dma_resv_unlock(dmabuf->resv); + if (atomic_dec_and_test(&dmabuf->resv_user)) + complete(&dmabuf->done); + +print_name: return dynamic_dname(dentry, buffer, buflen, "/%s:%s", dentry->d_name.name, ret > 0 ? name : ""); } @@ -85,6 +94,10 @@ static int dma_buf_release(struct inode return -EINVAL; dmabuf = file->private_data; + file->f_path.dentry->d_fsdata = NULL; + atomic_inc(&dmabuf->resv_user); + if (!atomic_dec_and_test(&dmabuf->resv_user)) + wait_for_completion(&dmabuf->done); BUG_ON(dmabuf->vmapping_counter); @@ -562,6 +575,7 @@ struct dma_buf *dma_buf_export(const str mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments); + init_completion(&dmabuf->done); mutex_lock(&db_list.lock); list_add(&dmabuf->list_node, &db_list.head);

5 years, 3 months

Re: [Linaro-mm-sig] [virtio-dev] [PATCH v2 4/4] drm/virtio: Support virtgpu exported resources

by Gerd Hoffmann

On Tue, Mar 03, 2020 at 11:42:22AM +0900, David Stevens wrote: > > cmd_p->hdr.ctx_id = > > > > Before this completion of this hypercall, this resource can be > > considered context local, while afterward it can be considered > > "exported". > > Maybe I'm misunderstanding render contexts, but exporting a resource > doesn't seem related to render contexts. It isn't indeed. Binding resources to contexts might need dma-buf imports/exports on the host side, but that is another story and not related to dma-buf exports inside the guest. cheers, Gerd

5 years, 4 months

Re: [Linaro-mm-sig] [PATCH v2 4/4] drm/virtio: Support virtgpu exported resources

by Gerd Hoffmann

Hi, > + if (vgdev->has_resource_assign_uuid) { > + spin_lock(&vgdev->resource_export_lock); > + if (bo->uuid_state == UUID_NOT_INITIALIZED) { > + bo->uuid_state = UUID_INITIALIZING; > + needs_init = true; > + } > + spin_unlock(&vgdev->resource_export_lock); > + > + if (needs_init) { > + ret = virtio_gpu_cmd_resource_assign_uuid(vgdev, bo); You can submit a fenced command, then wait on the fence here. Removes the need for UUID_INITIALIZING. Also note that this function will be called only once, on the first export. When exporting the same object again drm will simply reuse the existing dmabuf. You can drop UUID_NOT_INITIALIZED and needs_init. So you are left with only two uuid_state states. You could turn uuid into a pointer, so it gets only allocated when needed. Also uuid == NULL can be used for "uuid not available" then. cheers, Gerd

5 years, 4 months

Re: [Linaro-mm-sig] [PATCH v2 1/4] dma-buf: add support for virtio exported objects

by Gerd Hoffmann

On Mon, Mar 02, 2020 at 09:15:21PM +0900, David Stevens wrote: > This change adds a new dma-buf operation that allows dma-bufs to be used > by virtio drivers to share exported objects. The new operation allows > the importing driver to query the exporting driver for the UUID which > identifies the underlying exported object. > > Signed-off-by: David Stevens <stevensd(a)chromium.org> > --- > drivers/dma-buf/dma-buf.c | 14 ++++++++++++++ > include/linux/dma-buf.h | 22 ++++++++++++++++++++++ > 2 files changed, 36 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index d4097856c86b..a04632284ec2 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1158,6 +1158,20 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) > } > EXPORT_SYMBOL_GPL(dma_buf_vunmap); > > +#ifdef CONFIG_VIRTIO > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid) Hmm, I think I would drop the #ifdef cheers, Gerd

5 years, 4 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: free dmabuf->name in dma_buf_release()

by Andrew Morton

On Thu, 27 Feb 2020 13:38:03 -0800 Cong Wang <xiyou.wangcong(a)gmail.com> wrote: > On Tue, Feb 25, 2020 at 5:54 PM Andrew Morton <akpm(a)linux-foundation.org> wrote: > > > > On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang <xiyou.wangcong(a)gmail.com> wrote: > > > > > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set > > > it never gets freed. > > > > > > Free it in dma_buf_release(). > > > > > > ... > > > > > > --- a/drivers/dma-buf/dma-buf.c > > > +++ b/drivers/dma-buf/dma-buf.c > > > @@ -108,6 +108,7 @@ static int dma_buf_release(struct inode *inode, struct file *file) > > > dma_resv_fini(dmabuf->resv); > > > > > > module_put(dmabuf->owner); > > > + kfree(dmabuf->name); > > > kfree(dmabuf); > > > return 0; > > > } > > > > ow. Is that ioctl privileged? > > It looks unprivileged to me, as I don't see capable() called along > the path. > OK, thanks. I added cc:stable to my copy.

5 years, 4 months

Re: [Linaro-mm-sig] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2

by Christian König

Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware): > On 2/23/20 4:45 PM, Christian König wrote: >> Am 21.02.20 um 18:12 schrieb Daniel Vetter: >>> [SNIP] >>> Yeah the Great Plan (tm) is to fully rely on ww_mutex slowly >>> degenerating >>> into essentially a global lock. But only when there's actual contention >>> and thrashing. >> >> Yes exactly. A really big problem in TTM is currently that we drop >> the lock after evicting BOs because they tend to move in again >> directly after that. >> >> From practice I can also confirm that there is exactly zero benefit >> from dropping locks early and reacquire them for example for the VM >> page tables. That's just makes it more likely that somebody needs to >> roll back and this is what we need to avoid in the first place. > > If you have a benchmarking setup available it would be very > interesting for future reference to see how changing from WD to WW > mutexes affects the roll back frequency. WW is known to cause > rollbacks much less frequently but there is more work associated with > each rollback. Not of hand. To be honest I still have a hard time to get a grip on the difference between WD and WW from the algorithm point of view. So I can't judge that difference at all. >> Contention on BO locks during command submission is perfectly fine as >> long as this is as lightweight as possible while we don't have >> trashing. When we have trashing multi submission performance is best >> archived to just favor a single process to finish its business and >> block everybody else. > > Hmm. Sounds like we need a per-manager ww_rwsem protecting manager > allocation, taken in write-mode then there's thrashing. In read-mode > otherwise. That would limit the amount of "unnecessary" locks we'd > have to keep and reduce unwanted side-effects, (see below): Well per-manager (you mean per domain here don't you?) doesn't sound like that useful because we rarely use only one domain, but I'm actually questioning for quite a while if the per BO lock scheme was the right approach. See from the performance aspect the closest to ideal solution I can think of would be a ww_rwsem per user of a resource. In other words we don't lock BOs, but instead a list of all their users and when you want to evict a BO you need to walk that list and inform all users that the BO will be moving. During command submission you then have the fast path which rather just grabs the read side of the user lock and check if all BOs are still in the expected place. If some BOs were evicted you back off and start the slow path, e.g. maybe even copy additional data from userspace then grab the write side of the lock etc.. etc... That approach is similar to what we use in amdgpu with the per-VM BOs, but goes a step further. Problem is that we are so used to per BO locks in the kernel that this is probably not doable any more. >> Because of this I would actually vote for forbidding to release >> individual ww_mutex() locks in a context. > > Yes, I see the problem. > > But my first reaction is that this might have undersirable > side-effects. Let's say somebody wanted to swap the evicted BOs out? Please explain further, I off hand don't see the problem here. In general I actually wanted to re-work TTM in a way that BOs in the SYSTEM/SWAPABLE domain are always backed by a shmem file instead of the struct page array we currently have. > Or cpu-writes to them causing faults, that might also block the > mm_sem, which in turn blocks hugepaged? Mhm, I also only have a higher level view how hugepaged works so why does it grabs the mm_sem on the write side? Thanks, Christian. > > Still it's a fairly simple solution to a problem that seems otherwise > hard to solve efficiently. > > Thanks, > Thomas > > >> >> Regards, >> Christian. >> >>> -Daniel > >

5 years, 4 months

Re: [Linaro-mm-sig] [virtio-dev] Re: [PATCH 1/2] virtio: add dma-buf support for exported objects

by Gerd Hoffmann

On Wed, Feb 26, 2020 at 12:56:58PM +0900, David Stevens wrote: > On Tue, Feb 25, 2020 at 3:10 PM Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > > > How about dma_buf_{get,set}_uuid, simliar to dma_buf_set_name? > > While I'm not opposed to such an API, I'm also hesitant to make > changes to the dma-buf API for a single use case. See virtio-wayland discussion. I expect we will see more cases show up. Maybe this should even go one level up, to struct file. cheers, Gerd

5 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig