summaryrefslogtreecommitdiff
path: root/drivers/dma-buf/udmabuf.c
AgeCommit message (Collapse)AuthorFilesLines
2023-07-17Merge tag 'drm-misc-next-2023-07-13' of ↵Daniel Vetter1-2/+0
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.6: UAPI Changes: * fbdev: * Make fbdev userspace interfaces optional; only leaves the framebuffer console active * prime: * Support dma-buf self-import for all drivers automatically: improves support for many userspace compositors Cross-subsystem Changes: * backlight: * Fix interaction with fbdev in several drivers * base: Convert struct platform.remove to return void; part of a larger, tree-wide effort * dma-buf: Acquire reservation lock for mmap() in exporters; part of an on-going effort to simplify locking around dma-bufs * fbdev: * Use Linux device instead of fbdev device in many places * Use deferred-I/O helper macros in various drivers * i2c: Convert struct i2c from .probe_new to .probe; part of a larger, tree-wide effort * video: * Avoid including <linux/screen_info.h> Core Changes: * atomic: * Improve logging * prime: * Remove struct drm_driver.gem_prime_mmap plus driver updates: all drivers now implement this callback with drm_gem_prime_mmap() * gem: * Support execution contexts: provides locking over multiple GEM objects * ttm: * Support init_on_free * Swapout fixes Driver Changes: * accel: * ivpu: MMU updates; Support debugfs * ast: * Improve device-model detection * Cleanups * bridge: * dw-hdmi: Improve support for YUV420 bus format * dw-mipi-dsi: Fix enable/disable of DSI controller * lt9611uxc: Use MODULE_FIRMWARE() * ps8640: Remove broken EDID code * samsung-dsim: Fix command transfer * tc358764: Handle HS/VS polarity; Use BIT() macro; Various cleanups * Cleanups * ingenic: * Kconfig REGMAP fixes * loongson: * Support display controller * mgag200: * Minor fixes * mxsfb: * Support disabling overlay planes * nouveau: * Improve VRAM detection * Various fixes and cleanups * panel: * panel-edp: Support AUO B116XAB01.4 * Support Visionox R66451 plus DT bindings * Cleanups * ssd130x: * Support per-controller default resolution plus DT bindings * Reduce memory-allocation overhead * Cleanups * tidss: * Support TI AM625 plus DT bindings * Implement new connector model plus driver updates * vkms * Improve write-back support * Documentation fixes Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230713090830.GA23281@linux-uq9g
2023-06-21udmabuf: Don't assert held reservation lock for dma-buf mmappingDmitry Osipenko1-2/+0
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares udmabuf for the locking policy update. Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-4-dmitry.osipenko@collabora.com
2023-06-19udmabuf: revert 'Add support for mapping hugepages (v4)'Mike Kravetz1-41/+6
This effectively reverts commit 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)"). Recently, Junxiao Chang found a BUG with page map counting as described here [1]. This issue pointed out that the udmabuf driver was making direct use of subpages of hugetlb pages. This is not a good idea, and no other mm code attempts such use. In addition to the mapcount issue, this also causes issues with hugetlb vmemmap optimization and page poisoning. For now, remove hugetlb support. If udmabuf wants to be used on hugetlb mappings, it should be changed to only use complete hugetlb pages. This will require different alignment and size requirements on the UDMABUF_CREATE API. [1] https://lore.kernel.org/linux-mm/20230512072036.1027784-1-junxiao.chang@intel.com/ Link: https://lkml.kernel.org/r/20230608204927.88711-1-mike.kravetz@oracle.com Fixes: 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)") Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Dongwon Kim <dongwon.kim@intel.com> Cc: James Houghton <jthoughton@google.com> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Junxiao Chang <junxiao.chang@intel.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-04-13udmabuf: remove MODULE_LICENSE in non-modulesNick Alcock1-1/+0
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2022-11-18udmabuf: add vmap and vunmap methods to udmabuf_opsLukasz Wiecaszek1-0/+28
The reason behind that patch is associated with videobuf2 subsystem (or more genrally with v4l2 framework) and user created dma buffers (udmabuf). In some circumstances when dealing with V4L2_MEMORY_DMABUF buffers videobuf2 subsystem wants to use dma_buf_vmap() method on the attached dma buffer. As udmabuf does not have .vmap operation implemented, such dma_buf_vmap() natually fails. videobuf2_common: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each videobuf2_common: __prepare_dmabuf: buffer for plane 0 changed videobuf2_common: __prepare_dmabuf: failed to map dmabuf for plane 0 videobuf2_common: __buf_prepare: buffer preparation failed: -14 The patch itself seems to be strighforward. It adds implementation of .vmap and .vunmap methods to 'struct dma_buf_ops udmabuf_ops'. .vmap method itself uses vm_map_ram() to map pages linearly into the kernel virtual address space. .vunmap removes mapping created earlier by .vmap. All locking and 'vmapping counting' is done in dma_buf.c so it seems to be redundant/unnecessary in .vmap/.vunmap. Signed-off-by: Lukasz Wiecaszek <lukasz.wiecaszek@gmail.com> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221117171810.75637-1-lukasz.wiecaszek@gmail.com Signed-off-by: Christian König <christian.koenig@amd.com>
2022-11-11udmabuf: Assert held reservation lock for dma-buf mmappingDmitry Osipenko1-0/+3
When userspace mmaps dma-buf's fd, the dma-buf reservation lock must be held. Add locking sanity check to the dma-buf mmaping callback to ensure that the locking assumption won't regress in the future. Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221110201349.351294-4-dmitry.osipenko@collabora.com
2022-10-07Merge tag 'pull-file_inode' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull file_inode() updates from Al Vrio: "whack-a-mole: cropped up open-coded file_inode() uses..." * tag 'pull-file_inode' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: orangefs: use ->f_mapping _nfs42_proc_copy(): use ->f_mapping instead of file_inode()->i_mapping dma_buf: no need to bother with file_inode()->i_mapping nfs_finish_open(): don't open-code file_inode() bprm_fill_uid(): don't open-code file_inode() sgx: use ->f_mapping... exfat_iterate(): don't open-code file_inode(file) ibmvmc: don't open-code file_inode()
2022-09-02dma_buf: no need to bother with file_inode()->i_mappingAl Viro1-1/+1
->f_mapping will do just fine Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-25udmabuf: Set ubuf->sg = NULL if the creation of sg table failsVivek Kasireddy1-3/+6
When userspace tries to map the dmabuf and if for some reason (e.g. OOM) the creation of the sg table fails, ubuf->sg needs to be set to NULL. Otherwise, when the userspace subsequently closes the dmabuf fd, we'd try to erroneously free the invalid sg table from release_udmabuf resulting in the following crash reported by syzbot: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 3609 Comm: syz-executor487 Not tainted 5.19.0-syzkaller-13930-g7ebfc85e2cd7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline] RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline] RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 04 00 00 48 8d 7d 0c 4c 8b 63 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 e2 RSP: 0018:ffffc900037efd30 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8cb67800 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff84ad27e0 RDI: 0000000000000000 RBP: fffffffffffffff4 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 000000000008c07c R12: ffff88801fa05000 R13: ffff888073db07e8 R14: ffff888025c25440 R15: 0000000000000000 FS: 0000555555fc4300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc1c0ce06e4 CR3: 00000000715e6000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_buf_release+0x157/0x2d0 drivers/dma-buf/dma-buf.c:78 __dentry_kill+0x42b/0x640 fs/dcache.c:612 dentry_kill fs/dcache.c:733 [inline] dput+0x806/0xdb0 fs/dcache.c:913 __fput+0x39c/0x9d0 fs/file_table.c:333 task_work_run+0xdd/0x1a0 kernel/task_work.c:177 ptrace_notify+0x114/0x140 kernel/signal.c:2353 ptrace_report_syscall include/linux/ptrace.h:420 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline] syscall_exit_work kernel/entry/common.c:249 [inline] syscall_exit_to_user_mode_prepare+0x129/0x280 kernel/entry/common.c:276 __syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline] syscall_exit_to_user_mode+0x9/0x50 kernel/entry/common.c:294 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fc1c0c35b6b Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44 RSP: 002b:00007ffd78a06090 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000007 RCX: 00007fc1c0c35b6b RDX: 0000000020000280 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 0000000000000007 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000000c R13: 0000000000000003 R14: 00007fc1c0cfe4a0 R15: 00007ffd78a06140 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline] RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline] RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114 Reported-by: syzbot+c80e9ef5d8bb45894db0@syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220825063522.801264-1-vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-07-13Backmerge tag 'v5.19-rc6' of ↵Dave Airlie1-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Backmerge in rc6 so I can merge msm next easier. Linux 5.19-rc6 Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-06-20udmabuf: add back sanity checkGerd Hoffmann1-1/+4
Check vm_fault->pgoff before using it. When we removed the warning, we also removed the check. Fixes: 7b26e4e2119d ("udmabuf: drop WARN_ON() check.") Reported-by: zdi-disclosures@trendmicro.com Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-06-09udmabuf: Set the DMA mask for the udmabuf device (v2)Vivek Kasireddy1-1/+17
If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2022-01-18udmabuf: validate ubuf->pagecountPavel Skripkin1-0/+4
Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array(). Fixes: fbb0de795078 ("Add udmabuf misc device") Reported-and-tested-by: syzbot+2c56b725ec547fa9cb29@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20211230142649.23022-1-paskripkin@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-08-12udmabuf: fix general protection fault in udmabuf_createPavel Skripkin1-2/+2
Syzbot reported general protection fault in udmabuf_create. The problem was in wrong error handling. In commit 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)") shmem_read_mapping_page() call was replaced with find_get_page_flags(), but find_get_page_flags() returns NULL on failure instead PTR_ERR(). Wrong error checking was causing GPF in get_page(), since passed page was equal to NULL. Fix it by changing if (IS_ER(!hpage)) to if (!hpage) Reported-by: syzbot+e9cd3122a37c5d6c51e8@syzkaller.appspotmail.com Fixes: 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210811175052.21254-1-paskripkin@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-06-23udmabuf: configurable list_limit and size_limit_mbDongwon Kim1-2/+7
Default list_limit and size_limit_mb are not big enough to cover all possible use cases. For example, list_limit could be well over its default, 1024 if only one or several pages are chained in all individual list entries when creating dmabuf backed by >4MB buffer. list_limit and size_limit_mb are now defined as module parameters so that those can be optionally configured by root with proper values to remove these constraints. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210611212107.9876-1-dongwon.kim@intel.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2021-06-10udmabuf: Add support for mapping hugepages (v4)Vivek Kasireddy1-7/+43
If the VMM's (Qemu) memory backend is backed up by memfd + Hugepages (hugetlbfs and not THP), we have to first find the hugepage(s) where the Guest allocations are located and then extract the regular 4k sized subpages from them. v2: Ensure that the subpage and hugepage offsets are calculated correctly when the range of subpage allocations cuts across multiple hugepages. v3: Instead of repeatedly looking up the hugepage for each subpage, only do it when the subpage allocation crosses over into a different hugepage. (suggested by Gerd and DW) v4: Fix the following warning identified by checkpatch: CHECK:OPEN_ENDED_LINE: Lines should not end with a '(' Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210609182915.592743-1-vivek.kasireddy@intel.com [ kraxel: one more checkpatch format tweak ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-23Merge tag 'drm-misc-next-2020-09-21' of ↵Dave Airlie1-0/+3
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: - virtio: Merged a PR for patches that will affect drm/virtio Core Changes: - dev: More devm_drm convertions and removal of drm_dev_init - atomic: Split out drm_atomic_helper_calc_timestamping_constants of drm_atomic_helper_update_legacy_modeset_state - ttm: More rework Driver Changes: - i915: selftests improvements - panfrost: support for Amlogic SoC - vc4: one fix - tree-wide: conversions to devm_drm_dev_alloc, - ast: simplifications of the atomic modesetting code - panfrost: multiple fixes - vc4: multiple fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200921152956.2gxnsdgxmwhvjyut@gilmour.lan
2020-09-10dmabuf: fix common struct sg_table related issuesMarek Szyprowski1-4/+3
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. To avoid such issues, lets use a common dma-mapping wrappers operating directly on the struct sg_table objects and use scatterlist page iterators where possible. This, almost always, hides references to the nents and orig_nents entries, making the code robust, easier to follow and copy/paste safe. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-07udmabuf: Add missing compact_ioctlKristian H. Kristensen1-0/+3
Make sure we can use this on mixed systems. Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200903181652.432067-1-hoegsberg@google.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-12-18udmabuf: fix dma-buf cpu accessGurchetan Singh1-4/+3
I'm just going to put Chia's review comment here since it sums the issue rather nicely: "(1) Semantically, a dma-buf is in DMA domain. CPU access from the importer must be surrounded by {begin,end}_cpu_access. This gives the exporter a chance to move the buffer to the CPU domain temporarily. (2) When the exporter itself has other means to do CPU access, it is only reasonable for the exporter to move the buffer to the CPU domain before access, and to the DMA domain after access. The exporter can potentially reuse {begin,end}_cpu_access for that purpose. Because of (1), udmabuf does need to implement the {begin,end}_cpu_access hooks. But "begin" should mean dma_sync_sg_for_cpu and "end" should mean dma_sync_sg_for_device. Because of (2), if userspace wants to continuing accessing through the memfd mapping, it should call udmabuf's {begin,end}_cpu_access to avoid cache issues." Reported-by: Chia-I Wu <olvaffe@gmail.com> Suggested-by: Chia-I Wu <olvaffe@gmail.com> Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191217230228.453-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-12-05udmabuf: implement begin_cpu_access/end_cpu_access hooksGurchetan Singh1-0/+39
With the misc device, we should end up using the result of get_arch_dma_ops(..) or dma-direct ops. This can allow us to have WC mappings in the guest after synchronization. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191203013627.85991-4-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-12-05udmabuf: separate out creating/destroying scatter-tableGurchetan Singh1-7/+19
These are nice functions and can be re-used. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191203013627.85991-3-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-12-05udmabuf: add a pointer to the miscdevice in dma-buf private dataGurchetan Singh1-4/+7
Will be used later. v2: rename 'udmabuf_misc' to 'device' (kraxel) Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191203013627.85991-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-12-05udmabuf: use cache_sgt_mapping optionGurchetan Singh1-4/+5
The GEM prime helpers do it, so should we. It's also possible to make it optional later. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20191203013627.85991-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-11-26udmabuf: Remove deleted map/unmap handlers.Maarten Lankhorst1-16/+0
Commit 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap handlers, but they still existed in udmabuf. Remove them there as well Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191126142516.630200-1-maarten.lankhorst@linux.intel.com
2019-06-05udmabuf: actually unmap the scatterlistLucas Stach1-0/+1
unmap_udmabuf fails to actually unmap the scatterlist, leaving dangling mappings around. Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: http://patchwork.freedesktop.org/patch/msgid/20190604202331.17482-1-l.stach@pengutronix.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-01-05drivers/dma-buf/udmabuf.c: convert to use vm_fault_tSouptick Joarder1-1/+1
Use new return type vm_fault_t for fault handler. Link: http://lkml.kernel.org/r/20181106173628.GA12989@jordon-HP-15-Notebook-PC Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-11-16udmabuf: set read/write flag when exportingGerd Hoffmann1-0/+1
Otherwise, mmap fails when done with PROT_WRITE. Suggested-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20181114122029.16766-1-kraxel@redhat.com
2018-09-14udmabuf: fix error code in map_udmabuf()Dan Carpenter1-1/+3
We accidentally forgot to set "ret" on this error path so it means we return NULL instead of an error pointer. The caller checks for NULL and changes it to an error pointer so it doesn't cause an issue at run time. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180914065615.GA12043@mwanda Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-09-12udmabuf: use sizeof(variable) instead of sizeof(type)Gerd Hoffmann1-3/+3
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-13-kraxel@redhat.com
2018-09-12udmabuf: drop WARN_ON() check.Gerd Hoffmann1-3/+0
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-12-kraxel@redhat.com
2018-09-12udmabuf: use ENOTTY for invalid ioctlsGerd Hoffmann1-1/+1
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-11-kraxel@redhat.com
2018-09-12udmabuf: use EBADFD in case we didn't got a memfdGerd Hoffmann1-2/+5
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-10-kraxel@redhat.com
2018-09-12udmabuf: improve udmabuf_create error handlingGerd Hoffmann1-13/+12
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-9-kraxel@redhat.com
2018-09-12udmabuf: rework limitsGerd Hoffmann1-2/+8
Create variable for the list length limit. Serves as documentation, also allows to make it a module parameter if needed. Also add a total size limit. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-8-kraxel@redhat.com
2018-09-12udmabuf: constify udmabuf_create argsGerd Hoffmann1-2/+2
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-6-kraxel@redhat.com
2018-09-12udmabuf: constify udmabuf_opsGerd Hoffmann1-1/+1
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-5-kraxel@redhat.com
2018-09-12udmabuf: use pgoff_t for pagecountGerd Hoffmann1-1/+1
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-4-kraxel@redhat.com
2018-09-12udmabuf: improve map_udmabuf error handlingGerd Hoffmann1-11/+10
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-3-kraxel@redhat.com
2018-09-12udmabuf: sort headers, drop uapi/ path prefixGerd Hoffmann1-9/+8
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180911134216.9760-2-kraxel@redhat.com
2018-09-05dma-buf/udmabuf: Fix NULL pointer dereference in udmabuf_createGustavo A. R. Silva1-1/+2
There is a potential execution path in which pointer memfd is NULL when passed as argument to fput(), hence there is a NULL pointer dereference in fput(). Fix this by null checking *memfd* before calling fput(). Addresses-Coverity-ID: 1473174 ("Explicit null dereferenced") Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180904190749.GA9308@embeddedor.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2018-09-03Add udmabuf misc deviceGerd Hoffmann1-0/+287
A driver to let userspace turn memfd regions into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some day to wayland server for seamless guest window display. qemu test branch: https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf Cc: David Airlie <airlied@linux.ie> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180827093444.23623-1-kraxel@redhat.com