Linaro-mm-sig October 2023

linaro-mm-sig@lists.linaro.org

24 participants
19 discussions

[RFC PATCH] dma-buf/dma-fence: Use a successful read_trylock() annotation for dma_fence_begin_signalling()

by Thomas Hellström

Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The driver might here use a utility that is annotated as intended for the dma-fence signalling critical path. Now if the upper layer isn't correctly annotated yet for whatever reason, resulting in /* Upper layer */ lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); We will receive a false lockdep locking order violation notification from dma_fence_begin_signalling(). However entering a dma-fence signalling critical section itself doesn't block and could not cause a deadlock. So use a successful read_trylock() annotation instead for dma_fence_begin_signalling(). That will make sure that the locking order is correctly registered in the first case, and doesn't register any locking order in the second case. The alternative is of course to make sure that the "Upper layer" is always correctly annotated. But experience shows that's not easily achievable in all cases. Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/dma-buf/dma-fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index f177c56269bb..17f632768ef9 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -308,8 +308,8 @@ bool dma_fence_begin_signalling(void) if (in_atomic()) return true; - /* ... and non-recursive readlock */ - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _RET_IP_); + /* ... and non-recursive successful read_trylock */ + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _RET_IP_); return false; } @@ -340,7 +340,7 @@ void __dma_fence_might_wait(void) lock_map_acquire(&dma_fence_lockdep_map); lock_map_release(&dma_fence_lockdep_map); if (tmp) - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _THIS_IP_); + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _THIS_IP_); } #endif -- 2.39.2

3 months

[PATCH] drm/shmem-helper: Remove duplicate include

by Jiapeng Chong

./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4567 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 4ea6507a77e5..f401df26facf 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 2.20.1.7.g153144c

9 months, 2 weeks

[syzbot] [dri?] KMSAN: uninit-value in drm_mode_setcrtc

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 2741f1b02117 string: use __builtin_memcpy() in strlcpy/str.. git tree: https://github.com/google/kmsan.git master console+strace: https://syzkaller.appspot.com/x/log.txt?x=17bb33d1280000 kernel config: https://syzkaller.appspot.com/x/.config?x=753079601b2300f9 dashboard link: https://syzkaller.appspot.com/bug?extid=4fad2e57beb6397ab2fc compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16d669a5280000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14d8f095280000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/ebd05512d8d7/disk-2741f1b0.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/aa555b09582c/vmlinux-2741f1b0.… kernel image: https://storage.googleapis.com/syzbot-assets/5ea0934e02cc/bzImage-2741f1b0.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4fad2e57beb6397ab2fc(a)syzkaller.appspotmail.com ===================================================== BUG: KMSAN: uninit-value in drm_mode_setcrtc+0x1ad3/0x24a0 drivers/gpu/drm/drm_crtc.c:896 drm_mode_setcrtc+0x1ad3/0x24a0 drivers/gpu/drm/drm_crtc.c:896 drm_ioctl_kernel+0x5ae/0x730 drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0xd12/0x1590 drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0x222/0x400 fs/ioctl.c:856 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716 slab_alloc_node mm/slub.c:3451 [inline] __kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490 __do_kmalloc_node mm/slab_common.c:965 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:979 kmalloc_array include/linux/slab.h:596 [inline] drm_mode_setcrtc+0x1dba/0x24a0 drivers/gpu/drm/drm_crtc.c:846 drm_ioctl_kernel+0x5ae/0x730 drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0xd12/0x1590 drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0x222/0x400 fs/ioctl.c:856 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 1 PID: 4955 Comm: syz-executor275 Not tainted 6.4.0-rc4-syzkaller-g2741f1b02117 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 ===================================================== --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to change bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

1 year

[RFC] drm/scheduler: Unwrap job dependencies

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> Container fences have burner contexts, which makes the trick to store at most one fence per context somewhat useless if we don't unwrap array or chain fences. Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- tbh, I'm not sure why we weren't doing this already, unless there is something I'm overlooking drivers/gpu/drm/scheduler/sched_main.c | 43 +++++++++++++++++--------- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index c2ee44d6224b..f59e5335afbb 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -41,20 +41,21 @@ * 4. Entities themselves maintain a queue of jobs that will be scheduled on * the hardware. * * The jobs in a entity are always scheduled in the order that they were pushed. */ #include <linux/kthread.h> #include <linux/wait.h> #include <linux/sched.h> #include <linux/completion.h> +#include <linux/dma-fence-unwrap.h> #include <linux/dma-resv.h> #include <uapi/linux/sched/types.h> #include <drm/drm_print.h> #include <drm/drm_gem.h> #include <drm/gpu_scheduler.h> #include <drm/spsc_queue.h> #define CREATE_TRACE_POINTS #include "gpu_scheduler_trace.h" @@ -665,41 +666,27 @@ void drm_sched_job_arm(struct drm_sched_job *job) sched = entity->rq->sched; job->sched = sched; job->s_priority = entity->rq - sched->sched_rq; job->id = atomic64_inc_return(&sched->job_id_count); drm_sched_fence_init(job->s_fence, job->entity); } EXPORT_SYMBOL(drm_sched_job_arm); -/** - * drm_sched_job_add_dependency - adds the fence as a job dependency - * @job: scheduler job to add the dependencies to - * @fence: the dma_fence to add to the list of dependencies. - * - * Note that @fence is consumed in both the success and error cases. - * - * Returns: - * 0 on success, or an error on failing to expand the array. - */ -int drm_sched_job_add_dependency(struct drm_sched_job *job, - struct dma_fence *fence) +static int _add_dependency(struct drm_sched_job *job, struct dma_fence *fence) { struct dma_fence *entry; unsigned long index; u32 id = 0; int ret; - if (!fence) - return 0; - /* Deduplicate if we already depend on a fence from the same context. * This lets the size of the array of deps scale with the number of * engines involved, rather than the number of BOs. */ xa_for_each(&job->dependencies, index, entry) { if (entry->context != fence->context) continue; if (dma_fence_is_later(fence, entry)) { dma_fence_put(entry); @@ -709,20 +696,46 @@ int drm_sched_job_add_dependency(struct drm_sched_job *job, } return 0; } ret = xa_alloc(&job->dependencies, &id, fence, xa_limit_32b, GFP_KERNEL); if (ret != 0) dma_fence_put(fence); return ret; } + +/** + * drm_sched_job_add_dependency - adds the fence as a job dependency + * @job: scheduler job to add the dependencies to + * @fence: the dma_fence to add to the list of dependencies. + * + * Note that @fence is consumed in both the success and error cases. + * + * Returns: + * 0 on success, or an error on failing to expand the array. + */ +int drm_sched_job_add_dependency(struct drm_sched_job *job, + struct dma_fence *fence) +{ + struct dma_fence_unwrap iter; + struct dma_fence *f; + int ret = 0; + + dma_fence_unwrap_for_each (f, &iter, fence) { + ret = _add_dependency(job, f); + if (ret) + break; + } + + return ret; +} EXPORT_SYMBOL(drm_sched_job_add_dependency); /** * drm_sched_job_add_resv_dependencies - add all fences from the resv to the job * @job: scheduler job to add the dependencies to * @resv: the dma_resv object to get the fences from * @usage: the dma_resv_usage to use to filter the fences * * This adds all fences matching the given usage from @resv to @job. * Must be called with the @resv lock held. -- 2.39.2

1 year

[PATCH v9 0/3] dma-fence: Deadline awareness (uabi edition)

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> This is a re-post of the remaining patches from: https://patchwork.freedesktop.org/series/114490/ Part of the hold-up of the remaining uabi patches was compositor support, but now an MR for kwin exists: https://invent.kde.org/plasma/kwin/-/merge_requests/4358 The syncobj userspace is: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21973 v1: https://patchwork.freedesktop.org/series/93035/ v2: Move filtering out of later deadlines to fence implementation to avoid increasing the size of dma_fence v3: Add support in fence-array and fence-chain; Add some uabi to support igt tests and userspace compositors. v4: Rebase, address various comments, and add syncobj deadline support, and sync_file EPOLLPRI based on experience with perf/ freq issues with clvk compute workloads on i915 (anv) v5: Clarify that this is a hint as opposed to a more hard deadline guarantee, switch to using u64 ns values in UABI (still absolute CLOCK_MONOTONIC values), drop syncobj related cap and driver feature flag in favor of allowing count_handles==0 for probing kernel support. v6: Re-work vblank helper to calculate time of _start_ of vblank, and work correctly if the last vblank event was more than a frame ago. Add (mostly unrelated) drm/msm patch which also uses the vblank helper. Use dma_fence_chain_contained(). More verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v7: Fix kbuild complaints about vblank helper. Add more docs. v8: Add patch to surface sync_file UAPI, and more docs updates. v9: Repost the remaining patches that expose new uabi to userspace. Rob Clark (3): drm/syncobj: Add deadline support for syncobj waits dma-buf/sync_file: Add SET_DEADLINE ioctl dma-buf/sw_sync: Add fence deadline support drivers/dma-buf/dma-fence.c | 3 +- drivers/dma-buf/sw_sync.c | 82 ++++++++++++++++++++++++++++++++++ drivers/dma-buf/sync_debug.h | 2 + drivers/dma-buf/sync_file.c | 19 ++++++++ drivers/gpu/drm/drm_syncobj.c | 64 ++++++++++++++++++++------ include/uapi/drm/drm.h | 17 +++++++ include/uapi/linux/sync_file.h | 22 +++++++++ 7 files changed, 195 insertions(+), 14 deletions(-) -- 2.41.0

1 year

[PATCH v2 0/6] DRM driver for verisilicon

by Keith Zhao

This patch is a drm driver for Starfive Soc JH7110, I am sending Drm driver part and HDMI driver part. We used GEM framework for buffer management , and for buffer allocation,we use DMA APIs. the Starfive HDMI servers as interface between a LCD Controller and a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and one HDMI transmitter PHY. (Sound support is not include in this patch) This patchset should be applied after the patchset: https://patchwork.kernel.org/project/linux-clk/cover/20230713113902.56519-1… V1: Changes since v1: - Further standardize the yaml file. - Dts naming convention improved. - Fix the problem of compiling and loading ko files. - Use drm new api to automatically manage resources. - Drop struct vs_crtc_funcs&vs_plane_funcs��subdivide the plane's help interface - Reduce the modifiers unused. - Optimize the hdmi driver code V2: Changes since v2: - fix the error about checking the yaml file. - match drm driver GEM DMA API. - Delete the custom crtc property . - hdmi use drmm_ new api to automatically manage resources. - update the modifiers comments. - enabling KASAN, fix the error during removing module Keith Zhao (6): dt-bindings: display: Add yamls for JH7110 display system riscv: dts: starfive: jh7110: add dc controller and hdmi node drm/fourcc: Add drm/vs tiled modifiers drm/vs: Register DRM device drm/vs: Add KMS crtc&plane drm/vs: Add hdmi driver .../starfive/starfive,display-subsystem.yaml | 41 + .../starfive/starfive,jh7110-dc8200.yaml | 109 + .../starfive/starfive,jh7110-inno-hdmi.yaml | 85 + MAINTAINERS | 7 + .../jh7110-starfive-visionfive-2.dtsi | 91 + arch/riscv/boot/dts/starfive/jh7110.dtsi | 41 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/verisilicon/Kconfig | 21 + drivers/gpu/drm/verisilicon/Makefile | 12 + drivers/gpu/drm/verisilicon/starfive_hdmi.c | 949 ++++++++ drivers/gpu/drm/verisilicon/starfive_hdmi.h | 295 +++ drivers/gpu/drm/verisilicon/vs_crtc.c | 257 +++ drivers/gpu/drm/verisilicon/vs_crtc.h | 43 + drivers/gpu/drm/verisilicon/vs_dc.c | 1002 +++++++++ drivers/gpu/drm/verisilicon/vs_dc.h | 80 + drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1959 +++++++++++++++++ drivers/gpu/drm/verisilicon/vs_dc_hw.h | 492 +++++ drivers/gpu/drm/verisilicon/vs_drv.c | 234 ++ drivers/gpu/drm/verisilicon/vs_drv.h | 31 + drivers/gpu/drm/verisilicon/vs_modeset.c | 36 + drivers/gpu/drm/verisilicon/vs_modeset.h | 10 + drivers/gpu/drm/verisilicon/vs_plane.c | 526 +++++ drivers/gpu/drm/verisilicon/vs_plane.h | 58 + drivers/gpu/drm/verisilicon/vs_type.h | 69 + include/uapi/drm/drm_fourcc.h | 57 + include/uapi/drm/vs_drm.h | 50 + 27 files changed, 6558 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,jh7110-inno-hdmi.yaml create mode 100644 drivers/gpu/drm/verisilicon/Kconfig create mode 100644 drivers/gpu/drm/verisilicon/Makefile create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h create mode 100644 include/uapi/drm/vs_drm.h -- 2.34.1

1 year

[syzbot] [dri?] kernel BUG in vmf_insert_pfn_prot (2)

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 9e6c269de404 Merge tag 'i2c-for-6.5-rc7' of git://git.kern.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=110b32d3a80000 kernel config: https://syzkaller.appspot.com/x/.config?x=aa796b6080b04102 dashboard link: https://syzkaller.appspot.com/bug?extid=398e17b61dab22cc56bc compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14284307a80000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/481d8421bfb2/disk-9e6c269d.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/5ec626f94634/vmlinux-9e6c269d.… kernel image: https://storage.googleapis.com/syzbot-assets/ab1e59619bd6/bzImage-9e6c269d.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+398e17b61dab22cc56bc(a)syzkaller.appspotmail.com ------------[ cut here ]------------ kernel BUG at mm/memory.c:2214! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 5157 Comm: syz-executor.3 Not tainted 6.5.0-rc6-syzkaller-00253-g9e6c269de404 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2214 Code: 0f 0b e8 0c 4f c0 ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 88 4a c0 ff 49 83 ff 20 0f 85 aa fe ff ff e8 e9 4e c0 ff <0f> 0b 48 bd ff ff ff ff ff ff 0f 00 e8 d8 4e c0 ff 4c 89 f6 48 89 RSP: 0018:ffffc9000415f750 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880275a0d00 RCX: 0000000000000000 RDX: ffff888018379dc0 RSI: ffffffff81c5b9b7 RDI: 0000000000000007 RBP: 000000000c140477 R08: 0000000000000007 R09: 0000000000000020 R10: 0000000000000020 R11: 000000000000001f R12: 0000000020ffc000 R13: 1ffff9200082beeb R14: 000000000007e79e R15: 0000000000000020 FS: 00007f235bd9a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ffc000 CR3: 0000000022a32000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> drm_gem_shmem_fault+0x1ea/0x3a0 drivers/gpu/drm/drm_gem_shmem_helper.c:563 __do_fault+0x107/0x5f0 mm/memory.c:4198 do_read_fault mm/memory.c:4547 [inline] do_fault mm/memory.c:4670 [inline] do_pte_missing mm/memory.c:3664 [inline] handle_pte_fault mm/memory.c:4939 [inline] __handle_mm_fault+0x27e0/0x3b80 mm/memory.c:5079 handle_mm_fault+0x2ab/0x9d0 mm/memory.c:5233 do_user_addr_fault+0x446/0xfc0 arch/x86/mm/fault.c:1392 handle_page_fault arch/x86/mm/fault.c:1486 [inline] exc_page_fault+0x5c/0xd0 arch/x86/mm/fault.c:1542 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:rep_movs_alternative+0x4a/0xb0 arch/x86/lib/copy_user_64.S:71 Code: 75 f1 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8b 06 48 89 07 48 83 c6 08 48 83 c7 08 83 e9 08 74 df 83 f9 08 73 e8 eb c9 <f3> a4 c3 0f 1f 00 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 4c RSP: 0018:ffffc9000415fb50 EFLAGS: 00050206 RAX: 0000000000000001 RBX: 0000000020ffc000 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000020ffc000 RDI: ffff88807b764000 RBP: 0000000000001000 R08: 0000000000000001 R09: ffffed100f6ec9ff R10: ffff88807b764fff R11: 0000000000000000 R12: 0000000020ffd000 R13: ffff88807b764000 R14: 0000000000000000 R15: 0000000020ffc000 copy_user_generic arch/x86/include/asm/uaccess_64.h:112 [inline] raw_copy_from_user arch/x86/include/asm/uaccess_64.h:127 [inline] _copy_from_user+0xc2/0xf0 lib/usercopy.c:23 copy_from_user include/linux/uaccess.h:183 [inline] snd_rawmidi_kernel_write1+0x360/0x860 sound/core/rawmidi.c:1618 snd_rawmidi_write+0x278/0xc10 sound/core/rawmidi.c:1687 vfs_write+0x2a4/0xe40 fs/read_write.c:582 ksys_write+0x1f0/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f235b07cae9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f235bd9a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f235b19bf80 RCX: 00007f235b07cae9 RDX: 00000000fffffd2c RSI: 0000000020000000 RDI: 0000000000000005 RBP: 00007f235b0c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f235b19bf80 R15: 00007ffd9cdf0fe8 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:vmf_insert_pfn_prot+0x247/0x430 mm/memory.c:2214 Code: 0f 0b e8 0c 4f c0 ff 49 89 ef bf 20 00 00 00 41 83 e7 28 4c 89 fe e8 88 4a c0 ff 49 83 ff 20 0f 85 aa fe ff ff e8 e9 4e c0 ff <0f> 0b 48 bd ff ff ff ff ff ff 0f 00 e8 d8 4e c0 ff 4c 89 f6 48 89 RSP: 0018:ffffc9000415f750 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8880275a0d00 RCX: 0000000000000000 RDX: ffff888018379dc0 RSI: ffffffff81c5b9b7 RDI: 0000000000000007 RBP: 000000000c140477 R08: 0000000000000007 R09: 0000000000000020 R10: 0000000000000020 R11: 000000000000001f R12: 0000000020ffc000 R13: 1ffff9200082beeb R14: 000000000007e79e R15: 0000000000000020 FS: 00007f235bd9a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93c20ffac1 CR3: 0000000022a32000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 ---------------- Code disassembly (best guess): 0: 75 f1 jne 0xfffffff3 2: c3 ret 3: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) a: 00 00 00 00 e: 66 90 xchg %ax,%ax 10: 48 8b 06 mov (%rsi),%rax 13: 48 89 07 mov %rax,(%rdi) 16: 48 83 c6 08 add $0x8,%rsi 1a: 48 83 c7 08 add $0x8,%rdi 1e: 83 e9 08 sub $0x8,%ecx 21: 74 df je 0x2 23: 83 f9 08 cmp $0x8,%ecx 26: 73 e8 jae 0x10 28: eb c9 jmp 0xfffffff3 * 2a: f3 a4 rep movsb %ds:(%rsi),%es:(%rdi) <-- trapping instruction 2c: c3 ret 2d: 0f 1f 00 nopl (%rax) 30: 4c 8b 06 mov (%rsi),%r8 33: 4c 8b 4e 08 mov 0x8(%rsi),%r9 37: 4c 8b 56 10 mov 0x10(%rsi),%r10 3b: 4c 8b 5e 18 mov 0x18(%rsi),%r11 3f: 4c rex.WR --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

1 year, 1 month

[PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap

by Yong Wu

This patchset consists of two parts, the first is from John and TJ. It adds some heap interfaces, then our kernel users could allocate buffer from special heap. The second part is adding MTK secure heap for SVP (Secure Video Path). A total of two heaps are added, one is mtk_svp and the other is mtk_svp_cma. The mtk_svp buffer is reserved for the secure world after bootup and it is used for ES/working buffer, while the mtk_svp_cma buffer is dynamically reserved for the secure world and will be get ready when we start playing secure videos, this heap is used for the frame buffer. Once the security video playing is complete, the CMA will be released. For easier viewing, I've split the new heap file into several patches. The consumers of new heap and new interfaces are our codec and drm which will send upstream soon, probably this week. Base on v6.6-rc1. John Stultz (2): dma-heap: Add proper kref handling on dma-buf heaps dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps T.J. Mercier (1): dma-buf: heaps: Deduplicate docs and adopt common format Yong Wu (6): dma-buf: heaps: Initialise MediaTek secure heap dma-buf: heaps: mtk_sec_heap: Initialise tee session dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing dma-buf: heaps: mtk_sec_heap: Add dma_ops dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP dma_buf: heaps: mtk_sec_heap: Add a new CMA heap .../mediatek,secure_cma_chunkmem.yaml | 42 ++ drivers/dma-buf/dma-heap.c | 127 +++-- drivers/dma-buf/heaps/Kconfig | 8 + drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/mtk_secure_heap.c | 458 ++++++++++++++++++ include/linux/dma-heap.h | 42 +- 6 files changed, 630 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c -- 2.18.0

1 year, 1 month

Re: [RFC PATCH] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

Hi, On Tue, Oct 24, 2023 at 07:14:25PM +0200, Marco Pagani wrote: > >> +static void drm_gem_shmem_test_obj_create_private(struct kunit *test) > >> +{ > >> + struct fake_dev *fdev = test->priv; > >> + struct drm_gem_shmem_object *shmem; > >> + struct drm_gem_object *gem_obj; > >> + struct dma_buf buf_mock; > >> + struct dma_buf_attachment attach_mock; > >> + struct sg_table *sgt; > >> + char *buf; > >> + int ret; > >> + > >> + /* Create a mock scatter/gather table */ > >> + buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL); > >> + KUNIT_ASSERT_NOT_NULL(test, buf); > >> + > >> + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); > >> + KUNIT_ASSERT_NOT_NULL(test, sgt); > >> + > >> + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > >> + KUNIT_ASSERT_EQ(test, ret, 0); > >> + sg_init_one(sgt->sgl, buf, TEST_SIZE); > >> + > >> + /* Init a mock DMA-BUF */ > >> + buf_mock.size = TEST_SIZE; > >> + attach_mock.dmabuf = &buf_mock; > >> + > >> + gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); > >> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); > >> + KUNIT_ASSERT_EQ(test, gem_obj->size, TEST_SIZE); > >> + KUNIT_ASSERT_NULL(test, gem_obj->filp); > >> + KUNIT_ASSERT_NOT_NULL(test, gem_obj->funcs); > >> + > >> + shmem = to_drm_gem_shmem_obj(gem_obj); > >> + KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); > >> + > >> + /* The scatter/gather table is freed by drm_gem_shmem_free */ > >> + drm_gem_shmem_free(shmem); > >> +} > > > > KUNIT_ASSERT_* will stop the execution of the test on failure, you > > should probably use a bit more of KUNIT_EXPECT_* calls otherwise you'll > > leak resources. > > > > You also probably want to use a kunit_action to clean up and avoid that > > whole discussion > > > > You are right. I slightly prefer using KUnit expectations (unless actions > are strictly necessary) since I feel using actions makes test cases a bit > less straightforward to understand. Is this okay for you? I disagree. Actions make it easier to reason about, even when comparing assertion vs expectation Like, for the call to sg_alloc_table and drm_gem_shmem_prime_import_sg_table(), the reasonable use of assert vs expect would be something like: sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); KUNIT_ASSERT_NOT_NULL(test, sgt); ret = sg_alloc_table(sgt, 1, GFP_KERNEL); KUNIT_ASSERT_EQ(test, ret, 0); /* * Here, it's already not super clear whether you want to expect vs * assert. expect will make you handle the failure case later, assert will * force you to call kfree on sgt. Both kind of suck in their own ways. */ sg_init_one(sgt->sgl, buf, TEST_SIZE); gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); /* * If the assert fails, we forgot to call sg_free_table(sgt) and kfree(sgt). */ KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); KUNIT_EXPECT_NULL(test, gem_obj->filp); KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); /* * And here we have to handle the case where the expectation was wrong, * but the test still continued. */ But if you're not using an action, you still have to call kfree(sgt), which means that you might still shmem = to_drm_gem_shmem_obj(gem_obj); KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); /* * If the assertion fails, we now have to call drm_gem_shmem_free(shmem) */ /* The scatter/gather table is freed by drm_gem_shmem_free */ drm_gem_shmem_free(shmem); /* everything's fine now */ The semantics around drm_gem_shmem_free make it a bit convoluted, but doing it using goto/labels, plus handling the assertions and error reporting would be difficult. Using actions, we have: sgt = kzalloc(sizeof(*sgt), GFP_KERNEL); KUNIT_ASSERT_NOT_NULL(test, sgt); ret = kunit_add_action_or_reset(test, kfree_wrapper, sgt); KUNIT_ASSERT_EQ(test, ret, 0); ret = sg_alloc_table(sgt, 1, GFP_KERNEL); KUNIT_ASSERT_EQ(test, ret, 0); ret = kunit_add_action_or_reset(test, sg_free_table_wrapper, sgt); KUNIT_ASSERT_EQ(test, ret, 0); sg_init_one(sgt->sgl, buf, TEST_SIZE); gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_mock, sgt); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj); KUNIT_EXPECT_EQ(test, gem_obj->size, TEST_SIZE); KUNIT_EXPECT_NULL(test, gem_obj->filp); KUNIT_EXPECT_NOT_NULL(test, gem_obj->funcs); /* drm_gem_shmem_free will free the struct sg_table itself */ kunit_remove_action(test, sg_free_table_wrapper, sgt); kunit_remove_action(test, kfree_wrapper, sgt); shmem = to_drm_gem_shmem_obj(gem_obj); KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt); ret = kunit_add_action_or_reset(test, drm_gem_shmem_free_wrapper, shmem); KUNIT_ASSERT_EQ(test, ret, 0); The last one is arguable, but for the previous ones it makes error handling much more convenient and easy to reason about. The wrappers are also a bit inconvenient to use, but it's mostly there to avoid a compiler warning at the moment. This patch will help hopefully: https://lore.kernel.org/linux-kselftest/20230915050125.3609689-1-davidgow@g… Maxime

1 year, 2 months

Re: [PATCH] drm: docs: Remove item from TODO list

by Maxime Ripard

Hi, On Mon, Oct 23, 2023 at 10:25:50AM -0700, Doug Anderson wrote: > On Mon, Oct 23, 2023 at 9:31 AM Yuran Pereira <yuran.pereira(a)hotmail.com> wrote: > > > > Since "Clean up checks for already prepared/enabled in panels" has > > already been done and merged [1], I think there is no longer a need > > for this item to be in the gpu TODO. > > > > [1] https://patchwork.freedesktop.org/patch/551421/ > > > > Signed-off-by: Yuran Pereira <yuran.pereira(a)hotmail.com> > > --- > > Documentation/gpu/todo.rst | 25 ------------------------- > > 1 file changed, 25 deletions(-) > > It's not actually all done. It's in a bit of a limbo state right now, > unfortunately. I landed all of the "simple" cases where panels were > needlessly tracking prepare/enable, but the less simple cases are > still outstanding. > > Specifically the issue is that many panels have code to properly power > cycle themselves off at shutdown time and in order to do that they > need to keep track of the prepare/enable state. After a big, long > discussion [1] it was decided that we could get rid of all the panel > code handling shutdown if only all relevant DRM KMS drivers would > properly call drm_atomic_helper_shutdown(). > > I made an attempt to get DRM KMS drivers to call > drm_atomic_helper_shutdown() [2] [3] [4]. I was able to land the > patches that went through drm-misc, but currently many of the > non-drm-misc ones are blocked waiting for attention. > > ...so things that could be done to help out: > > a) Could review patches that haven't landed in [4]. Maybe adding a > Reviewed-by tag would help wake up maintainers? > > b) Could see if you can identify panels that are exclusively used w/ > DRM drivers that have already been converted and then we could post > patches for just those panels. I have no idea how easy this task would > be. Is it enough to look at upstream dts files by "compatible" string? I think it is, yes. Maxime

1 year, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig October 2023