Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
3081 discussions

Re: [Linaro-mm-sig] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

by Christoph Hellwig

On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. The drivers I looked at want a list of IOVA address, aligned to the device "page size". What other data do drivers want? Execept for the software protocol stack drivers, which of couse need pages for the stack futher down. > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory bio_vecs itself don't have the chaining, but the bios build around them do. But each entry can map a huge pile. If needed we could use the same chaining scheme we use for scatterlists for bio_vecs as well, but lets see if we really end up needing that. > So I'm guessing the path forward is something like > > - Add some generic dma_sg data structure and helper > - Add dma mapping code to go from pages to dma_sg That has been on my todo list for a while. All the DMA consolidatation is to prepare for that and we're finally getting close.

5 years, 7 months

Re: [Linaro-mm-sig] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function

by Christian König

Am 12.03.20 um 15:19 schrieb Jason Gunthorpe: > On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote: >> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote: >>> But how should we then deal with all the existing interfaces which already >>> take a scatterlist/sg_table ? >>> >>> The whole DMA-buf design and a lot of drivers are build around >>> scatterlist/sg_table and to me that actually makes quite a lot of sense. >>> >> Replace them with a saner interface that doesn't take a scatterlist. >> At very least for new functionality like peer to peer DMA, but >> especially this code would also benefit from a general move away >> from the scatterlist. > If dma buf can do P2P I'd like to see support for consuming a dmabuf > in RDMA. That would indeed be awesome. > Looking at how.. there is an existing sgl based path starting > from get_user_pages through dma map to the drivers. (ib_umem) > > I can replace the driver part with something else (dma_sg), but not > until we get a way to DMA map pages directly into that something > else.. > > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. Yeah that's my concern as well. For GPU drivers I don't think we need the struct pages anywhere, but that might not be true for others. >>> I mean we could come up with a new structure for this, but to me that just >>> looks like reinventing the wheel. Especially since drivers need to be able >>> to handle both I/O to system memory and I/O to PCIe BARs. >> The structure for holding the struct page side of the scatterlist is >> called struct bio_vec, so far mostly used by the block and networking >> code. > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory > >> The structure for holding dma addresses doesn't really exist >> in a generic form, but would be an array of these structures: >> >> struct dma_sg { >> dma_addr_t addr; >> u32 len; >> }; > Same question, RDMA needs to represent gigabytes of pages in a DMA > list, we will need some generic way to handle that. I suspect GPU has > a similar need? Can it be accomidated in some generic dma_sg? Yes, we easily have ranges of >1GB. So I would certainly say u64 for the len here. > So I'm guessing the path forward is something like > > - Add some generic dma_sg data structure and helper > - Add dma mapping code to go from pages to dma_sg > - Rework RDMA to use dma_sg and the new dma mapping code > - Rework dmabuf to support dma mapping to a dma_sg > - Rework GPU drivers to use dma_sg > - Teach p2pdma to generate a dma_sg from a BAR page list > - This series > > ? Sounds pretty much like a plan to me, but unfortunately like a rather huge one. Because of this and cause I don't know if all drivers can live with dma_sg I'm not sure if we shouldn't have the switch from scatterlist to dma_sg separately to this peer2peer work. Christian. > > Jason

5 years, 7 months

P2P for DMA-buf

by Christian König

This is the third and final part of my series to start supporting P2P with DMA-buf. The implementation is straight forward, apart from a helper to aid constructing scatterlists without having struct pages we only add a new flag indicating that an DMA-buf importer can handle peer2peer. The exporter can then check if P2P is general possible using the pci_p2pdma_distance_many() function and if necessary can also clear the flag. The rest is an example how to implementing the necessary functionality into the amdgpu driver to setup scatterlists pointing to device memory. Please review and comment, Christian.

5 years, 7 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: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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 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, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig