Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

5 participants
2541 discussions

Re: [syzbot] KASAN: use-after-free Read in task_work_run (2)

by Dmitry Vyukov

On Tue, 6 Sept 2022 at 09:36, syzbot <syzbot+9228d6098455bb209ec8(a)syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: c5e4d5e99162 Merge tag 'fscache-fixes-20220831' of git://g.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=142e0e1b080000 > kernel config: https://syzkaller.appspot.com/x/.config?x=9c5c41fc03fda66f > dashboard link: https://syzkaller.appspot.com/bug?extid=9228d6098455bb209ec8 > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+9228d6098455bb209ec8(a)syzkaller.appspotmail.com Looks like the issue is in dma-buf.c +dma-buf.c maintainers > ================================================================== > BUG: KASAN: use-after-free in task_work_run+0x126/0x1c0 kernel/task_work.c:176 > Read of size 8 at addr ffff88801d1fe500 by task syz-executor.2/18582 > > CPU: 0 PID: 18582 Comm: syz-executor.2 Not tainted 6.0.0-rc3-syzkaller-00031-gc5e4d5e99162 #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 > print_address_description+0x65/0x4b0 mm/kasan/report.c:317 > print_report+0x108/0x220 mm/kasan/report.c:433 > kasan_report+0xfb/0x130 mm/kasan/report.c:495 > task_work_run+0x126/0x1c0 kernel/task_work.c:176 > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > exit_to_user_mode_loop+0x134/0x160 kernel/entry/common.c:169 > exit_to_user_mode_prepare+0xad/0x110 kernel/entry/common.c:201 > __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] > syscall_exit_to_user_mode+0x2e/0x60 kernel/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > RIP: 0033:0x7f287f289279 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 b8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007f28804cd168 EFLAGS: 00000246 ORIG_RAX: 0000000000000119 > RAX: 0000000000000001 RBX: 00007f287f39bf80 RCX: 00007f287f289279 > RDX: 0000000000000001 RSI: 0000000020000000 RDI: 0000000000000003 > RBP: 00007f287f2e32e9 R08: 0000000000000000 R09: 0000000000000000 > R10: 00000000000006ff R11: 0000000000000246 R12: 0000000000000000 > R13: 00007ffd34f4ba0f R14: 00007f28804cd300 R15: 0000000000022000 > </TASK> > > Allocated by task 18586: > kasan_save_stack mm/kasan/common.c:38 [inline] > kasan_set_track mm/kasan/common.c:45 [inline] > set_alloc_info mm/kasan/common.c:437 [inline] > __kasan_slab_alloc+0xb2/0xe0 mm/kasan/common.c:470 > kasan_slab_alloc include/linux/kasan.h:224 [inline] > slab_post_alloc_hook mm/slab.h:727 [inline] > slab_alloc_node mm/slub.c:3243 [inline] > slab_alloc mm/slub.c:3251 [inline] > __kmem_cache_alloc_lru mm/slub.c:3258 [inline] > kmem_cache_alloc+0x1a6/0x310 mm/slub.c:3268 > kmem_cache_zalloc include/linux/slab.h:723 [inline] > __alloc_file+0x26/0x230 fs/file_table.c:138 > alloc_empty_file+0xa9/0x1b0 fs/file_table.c:187 > alloc_file+0x58/0x5e0 fs/file_table.c:229 > alloc_file_pseudo+0x260/0x300 fs/file_table.c:272 > dma_buf_getfile drivers/dma-buf/dma-buf.c:534 [inline] > dma_buf_export+0x634/0x920 drivers/dma-buf/dma-buf.c:652 > drm_gem_dmabuf_export drivers/gpu/drm/drm_prime.c:253 [inline] > drm_gem_prime_export+0x255/0x400 drivers/gpu/drm/drm_prime.c:895 > export_and_register_object drivers/gpu/drm/drm_prime.c:397 [inline] > drm_gem_prime_handle_to_fd+0x3e6/0x530 drivers/gpu/drm/drm_prime.c:465 > drm_ioctl_kernel+0x33e/0x4f0 drivers/gpu/drm/drm_ioctl.c:782 > drm_ioctl+0x626/0xa10 drivers/gpu/drm/drm_ioctl.c:885 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:870 [inline] > __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Freed by task 18595: > kasan_save_stack mm/kasan/common.c:38 [inline] > kasan_set_track+0x4c/0x70 mm/kasan/common.c:45 > kasan_set_free_info+0x1f/0x40 mm/kasan/generic.c:370 > ____kasan_slab_free+0xd8/0x120 mm/kasan/common.c:367 > kasan_slab_free include/linux/kasan.h:200 [inline] > slab_free_hook mm/slub.c:1754 [inline] > slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1780 > slab_free mm/slub.c:3534 [inline] > kmem_cache_free+0x95/0x1d0 mm/slub.c:3551 > rcu_do_batch kernel/rcu/tree.c:2245 [inline] > rcu_core+0xa61/0x1710 kernel/rcu/tree.c:2505 > __do_softirq+0x382/0x793 kernel/softirq.c:571 > > Last potentially related work creation: > kasan_save_stack+0x3b/0x60 mm/kasan/common.c:38 > __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:348 > call_rcu+0x163/0x9c0 kernel/rcu/tree.c:2793 > task_work_run+0x146/0x1c0 kernel/task_work.c:177 > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > exit_to_user_mode_loop+0x134/0x160 kernel/entry/common.c:169 > exit_to_user_mode_prepare+0xad/0x110 kernel/entry/common.c:201 > __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] > syscall_exit_to_user_mode+0x2e/0x60 kernel/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Second to last potentially related work creation: > kasan_save_stack+0x3b/0x60 mm/kasan/common.c:38 > __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:348 > task_work_add+0x2f/0x200 kernel/task_work.c:48 > fput+0xdc/0x1a0 fs/file_table.c:381 > dma_buf_poll_cb drivers/dma-buf/dma-buf.c:213 [inline] > dma_buf_poll+0x53a/0x680 drivers/dma-buf/dma-buf.c:295 > vfs_poll include/linux/poll.h:88 [inline] > ep_item_poll fs/eventpoll.c:853 [inline] > ep_send_events fs/eventpoll.c:1692 [inline] > ep_poll+0xb27/0x1e60 fs/eventpoll.c:1821 > do_epoll_wait+0x1a2/0x210 fs/eventpoll.c:2256 > do_epoll_pwait fs/eventpoll.c:2290 [inline] > __do_sys_epoll_pwait fs/eventpoll.c:2303 [inline] > __se_sys_epoll_pwait+0x28e/0x480 fs/eventpoll.c:2297 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > The buggy address belongs to the object at ffff88801d1fe500 > which belongs to the cache filp of size 456 > The buggy address is located 0 bytes inside of > 456-byte region [ffff88801d1fe500, ffff88801d1fe6c8) > > The buggy address belongs to the physical page: > page:ffffea0000747f80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d1fe > head:ffffea0000747f80 order:1 compound_mapcount:0 compound_pincount:0 > memcg:ffff888072449c01 > flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) > raw: 00fff00000010200 ffffea00005ddf80 dead000000000002 ffff888140007a00 > raw: 0000000000000000 00000000000c000c 00000001ffffffff ffff888072449c01 > page dumped because: kasan: bad access detected > page_owner tracks the page as allocated > page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 3111, tgid 3111 (v4l_id), ts 20130623440, free_ts 19733718234 > prep_new_page mm/page_alloc.c:2532 [inline] > get_page_from_freelist+0x72b/0x7a0 mm/page_alloc.c:4283 > __alloc_pages+0x259/0x560 mm/page_alloc.c:5515 > alloc_slab_page+0x70/0xf0 mm/slub.c:1824 > allocate_slab+0x5e/0x520 mm/slub.c:1969 > new_slab mm/slub.c:2029 [inline] > ___slab_alloc+0x42e/0xce0 mm/slub.c:3031 > __slab_alloc mm/slub.c:3118 [inline] > slab_alloc_node mm/slub.c:3209 [inline] > slab_alloc mm/slub.c:3251 [inline] > __kmem_cache_alloc_lru mm/slub.c:3258 [inline] > kmem_cache_alloc+0x25d/0x310 mm/slub.c:3268 > kmem_cache_zalloc include/linux/slab.h:723 [inline] > __alloc_file+0x26/0x230 fs/file_table.c:138 > alloc_empty_file+0xa9/0x1b0 fs/file_table.c:187 > path_openat+0xf1/0x2e00 fs/namei.c:3677 > do_filp_open+0x275/0x500 fs/namei.c:3718 > do_sys_openat2+0x13b/0x500 fs/open.c:1311 > do_sys_open fs/open.c:1327 [inline] > __do_sys_openat fs/open.c:1343 [inline] > __se_sys_openat fs/open.c:1338 [inline] > __x64_sys_openat+0x243/0x290 fs/open.c:1338 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > page last free stack trace: > reset_page_owner include/linux/page_owner.h:24 [inline] > free_pages_prepare mm/page_alloc.c:1449 [inline] > free_pcp_prepare+0x812/0x900 mm/page_alloc.c:1499 > free_unref_page_prepare mm/page_alloc.c:3380 [inline] > free_unref_page+0x7d/0x630 mm/page_alloc.c:3476 > qlist_free_all+0x2b/0x70 mm/kasan/quarantine.c:187 > kasan_quarantine_reduce+0x169/0x180 mm/kasan/quarantine.c:294 > __kasan_slab_alloc+0x2f/0xe0 mm/kasan/common.c:447 > kasan_slab_alloc include/linux/kasan.h:224 [inline] > slab_post_alloc_hook mm/slab.h:727 [inline] > slab_alloc_node mm/slub.c:3243 [inline] > slab_alloc mm/slub.c:3251 [inline] > __kmem_cache_alloc_lru mm/slub.c:3258 [inline] > kmem_cache_alloc+0x1a6/0x310 mm/slub.c:3268 > vm_area_alloc+0x20/0xe0 kernel/fork.c:459 > mmap_region+0xb4a/0x16f0 mm/mmap.c:1732 > do_mmap+0x7a7/0xdf0 mm/mmap.c:1540 > vm_mmap_pgoff+0x1e5/0x2f0 mm/util.c:552 > ksys_mmap_pgoff+0x48c/0x6d0 mm/mmap.c:1586 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > Memory state around the buggy address: > ffff88801d1fe400: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc > ffff88801d1fe480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > >ffff88801d1fe500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff88801d1fe580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88801d1fe600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== > > > --- > 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. > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe(a)googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000fad77705e7fd40….

2 years, 4 months

[PATCH 0/4] dma-buf: To check enable signaling before signaled

by Arvind Yadav

TTM, GEM, DRM or the core DMA-buf framework are needs to enable software signaling before the fence is signaled. The core DMA-buf framework software can forget to call enable_signaling before the fence is signaled. It means framework code can forget to call dma_fence_enable_sw_signaling() before calling dma_fence_is_signaled(). To avoid this scenario on debug kernel, check the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT bit status before checking the MA_FENCE_FLAG_SIGNALED_BIT bit status to confirm that software signaling is enabled. Arvind Yadav (4): dma-buf: Check status of enable-signaling bit on debug drm/sched: Add callback and enable signaling on debug dma-buf: Add callback and enable signaling on debug dma-buf: Add callback and enable signaling on debug drivers/dma-buf/dma-fence.c | 17 ++++++++ drivers/dma-buf/st-dma-fence-chain.c | 17 ++++++++ drivers/dma-buf/st-dma-fence-unwrap.c | 54 +++++++++++++++++++++++++ drivers/dma-buf/st-dma-fence.c | 34 +++++++++++++++- drivers/dma-buf/st-dma-resv.c | 30 ++++++++++++++ drivers/gpu/drm/scheduler/sched_fence.c | 12 ++++++ drivers/gpu/drm/scheduler/sched_main.c | 4 +- include/linux/dma-fence.h | 5 +++ 8 files changed, 171 insertions(+), 2 deletions(-) -- 2.25.1

2 years, 4 months

Attention: your linaro-mm-sig@lists.linaro.org Account storage is almost full

by Noreply＠lists.linaro.org

2 years, 4 months

[syzbot] WARNING: refcount bug in drm_gem_object_handle_put_unlocked

by syzbot

Hello, syzbot found the following issue on: HEAD commit: a41a877bc12d Merge branch 'for-next/fixes' into for-kernelci git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci console output: https://syzkaller.appspot.com/x/log.txt?x=17ae17bd080000 kernel config: https://syzkaller.appspot.com/x/.config?x=5cea15779c42821c dashboard link: https://syzkaller.appspot.com/bug?extid=c512687fff9d22327436 compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 userspace arch: arm64 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e8fee5080000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16b6bf13080000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+c512687fff9d22327436(a)syzkaller.appspotmail.com ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 3029 at lib/refcount.c:28 refcount_warn_saturate+0x1a0/0x1c8 lib/refcount.c:28 Modules linked in: CPU: 0 PID: 3029 Comm: syz-executor717 Not tainted 6.0.0-rc2-syzkaller-16455-ga41a877bc12d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0x1a0/0x1c8 lib/refcount.c:28 lr : refcount_warn_saturate+0x1a0/0x1c8 lib/refcount.c:28 sp : ffff80001200baa0 x29: ffff80001200baa0 x28: 00000000000a201d x27: 0000000000002000 x26: dead000000000100 x25: 0000000000000000 x24: 0000000000000001 x23: 0000000000000001 x22: 0000000000000000 x21: 0000000000000000 x20: 0000000000000003 x19: ffff80000d937000 x18: 00000000000000c0 x17: ffff80000dd7a698 x16: ffff80000dbb8658 x15: ffff0000c10a4f80 x14: 0000000000000000 x13: 00000000ffffffff x12: ffff0000c10a4f80 x11: ff808000081c39dc x10: 0000000000000000 x9 : 9016e5cf66052a00 x8 : 9016e5cf66052a00 x7 : ffff800008197c8c x6 : 0000000000000000 x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 0000000000000026 Call trace: refcount_warn_saturate+0x1a0/0x1c8 lib/refcount.c:28 __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put include/linux/kref.h:64 [inline] __drm_gem_object_put include/drm/drm_gem.h:381 [inline] drm_gem_object_put include/drm/drm_gem.h:394 [inline] drm_gem_object_handle_put_unlocked+0x178/0x190 drivers/gpu/drm/drm_gem.c:240 drm_gem_object_release_handle+0x90/0xa8 drivers/gpu/drm/drm_gem.c:259 idr_for_each+0xf0/0x174 lib/idr.c:208 drm_gem_release+0x30/0x48 drivers/gpu/drm/drm_gem.c:932 drm_file_free+0x220/0x2cc drivers/gpu/drm/drm_file.c:281 drm_close_helper drivers/gpu/drm/drm_file.c:308 [inline] drm_release+0x108/0x22c drivers/gpu/drm/drm_file.c:495 __fput+0x198/0x3bc fs/file_table.c:320 ____fput+0x20/0x30 fs/file_table.c:353 task_work_run+0xc4/0x208 kernel/task_work.c:177 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x26c/0xbb8 kernel/exit.c:795 do_group_exit+0x60/0xe8 kernel/exit.c:925 __do_sys_exit_group kernel/exit.c:936 [inline] __se_sys_exit_group kernel/exit.c:934 [inline] __wake_up_parent+0x0/0x40 kernel/exit.c:934 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall arch/arm64/kernel/syscall.c:52 [inline] el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x48/0x154 arch/arm64/kernel/syscall.c:206 el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x18c/0x190 irq event stamp: 12698 hardirqs last enabled at (12697): [<ffff8000081c1c48>] __up_console_sem+0xb0/0xfc kernel/printk/printk.c:264 hardirqs last disabled at (12698): [<ffff80000bffe9cc>] el1_dbg+0x24/0x5c arch/arm64/kernel/entry-common.c:395 softirqs last enabled at (12442): [<ffff8000080102e4>] _stext+0x2e4/0x37c softirqs last disabled at (12417): [<ffff800008104658>] do_softirq_own_stack include/asm-generic/softirq_stack.h:10 [inline] softirqs last disabled at (12417): [<ffff800008104658>] invoke_softirq+0x70/0xbc kernel/softirq.c:452 ---[ end trace 0000000000000000 ]--- --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

2 years, 4 months

E-mail Account Notification For linaro-mm-sig@lists.linaro.org !!!

by Noreply＠lists.linaro.org

2 years, 4 months

[bug report] dma-buf: Add debug option

by yf.wang＠mediatek.com

Hi Daniel Vetter, The patch https://patchwork.freedesktop.org/patch/414455/: "dma-buf: Add debug option" from Jan. 15, 2021, leads to the following expection: Backtrace: [<ffffffc0081a2258>] atomic_notifier_call_chain+0x9c/0xe8 [<ffffffc0081a2d54>] notify_die+0x114/0x19c [<ffffffc0080348d8>] __die+0xec/0x468 [<ffffffc008034648>] die+0x54/0x1f8 [<ffffffc0080631e8>] die_kernel_fault+0x80/0xbc [<ffffffc0080630fc>] __do_kernel_fault+0x268/0x2d4 [<ffffffc008062c4c>] do_bad_area+0x68/0x148 [<ffffffc00a6dab34>] do_translation_fault+0xbc/0x108 [<ffffffc0080619f8>] do_mem_abort+0x6c/0x1e8 [<ffffffc00a68f5cc>] el1_abort+0x3c/0x64 [<ffffffc00a68f54c>] el1h_64_sync_handler+0x5c/0xa0 [<ffffffc008011ae4>] el1h_64_sync+0x78/0x80 [<ffffffc008063b9c>] dcache_inval_poc+0x40/0x58 [<ffffffc009236104>] iommu_dma_sync_sg_for_cpu+0x144/0x280 [<ffffffc0082b4870>] dma_sync_sg_for_cpu+0xbc/0x110 [<ffffffc002c7538c>] system_heap_dma_buf_begin_cpu_access+0x144/0x1e0 [system_heap] [<ffffffc0094154e4>] dma_buf_begin_cpu_access+0xa4/0x10c [<ffffffc004888df4>] isp71_allocate_working_buffer+0x3b0/0xe8c [mtk_hcp] [<ffffffc004884a20>] mtk_hcp_allocate_working_buffer+0xc0/0x108 [mtk_hcp] Because of CONFIG_DMABUF_DEBUG will default enable when DMA_API_DEBUG enable, and when not support dma coherent, since the main function of user calling dma_buf_begin_cpu_access and dma_buf_end_cpu_access is to do cache sync during dma_buf_map_attachment and dma_buf_unmap_attachment, which get PA error from sgtable by sg_phys(sg), this leads to the expection. 1.dma_buf_map_attachement() -.> mangle_sg_table(sg) // "sg->page_link ^= ~0xffUL" to rotate PA in this patch. 2.dma_buf_begin_cpu_access() -.> system_heap_dma_buf_begin_cpu_access() in system_heap.c // do cache sync if mapped attachment before -.> iommu_dma_sync_sg_for_cpu() in dma-iommu.c -.> arch_sync_dma_for_device(sg_phys(sg), sg->length, dir) // get PA error since PA mix up 3.dma_buf_end_cpu_access() and dma_buf_begin_cpu_access are similar. 4.dma_buf_unmap_attachement() -.> mangle_sg_table(sg) // "sg->page_link ^= ~0xffUL" to rotate PA drivers/dma-buf/Kconfig: config DMABUF_DEBUG bool "DMA-BUF debug checks" default y if DMA_API_DEBUG drivers/dma-buf/dma-buf.c: static void mangle_sg_table(struct sg_table *sg_table) { #ifdef CONFIG_DMABUF_DEBUG int i; struct scatterlist *sg; /* To catch abuse of the underlying struct page by importers mix * up the bits, but take care to preserve the low SG_ bits to * not corrupt the sgt. The mixing is undone in __unmap_dma_buf * before passing the sgt back to the exporter. */ for_each_sgtable_sg(sg_table, sg, i) sg->page_link ^= ~0xffUL; #endif } drivers/iommu/dma-iommu.c: static void iommu_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl, int nelems, enum dma_data_direction dir) { struct scatterlist *sg; int i; if (dev_is_dma_coherent(dev) && !dev_is_untrusted(dev)) return; for_each_sg(sgl, sg, nelems, i) { if (!dev_is_dma_coherent(dev)) arch_sync_dma_for_cpu(sg_phys(sg), sg->length, dir); if (is_swiotlb_buffer(sg_phys(sg))) swiotlb_tbl_sync_single(dev, sg_phys(sg), sg->length, dir, SYNC_FOR_CPU); } } Thanks, Yunfei.

2 years, 4 months

[PATCH v3 0/9] Move all drivers to a common dma-buf locking convention

by Dmitry Osipenko

Hello, This series moves all drivers to a dynamic dma-buf locking specification. From now on all dma-buf importers are made responsible for holding dma-buf's reservation lock around all operations performed over dma-bufs in accordance to the locking specification. This allows us to utilize reservation lock more broadly around kernel without fearing of a potential deadlocks. This patchset passes all i915 selftests. It was also tested using VirtIO, Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate), which covers majority of kernel drivers since rest of the drivers share same or similar code paths. Changelog: v3: - Factored out dma_buf_mmap_unlocked() and attachment functions into aseparate patches, like was suggested by Christian König. - Corrected and factored out dma-buf locking documentation into a separate patch, like was suggested by Christian König. - Intel driver dropped the reservation locking fews days ago from its BO-release code path, but we need that locking for the imported GEMs because in the end that code path unmaps the imported GEM. So I added back the locking needed by the imported GEMs, updating the "dma-buf attachment locking specification" patch appropriately. - Tested Nouveau+Intel dma-buf import/export combo. - Tested udmabuf import to i915/Nouveau/AMDGPU. - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed to switch to locked dma-buf vmapping in the drm/gem: Take reservation lock for vmap/vunmap operations" patch. In a result invalidated the Christian's r-b that he gave to v2. - Added locked dma-buf vmap/vunmap functions that are needed for fixing vmappping of Etnaviv, Panfrost and Lima drivers mentioned above. I actually had this change stashed for the drm-shmem shrinker patchset, but then realized that it's already needed by the dma-buf patches. Also improved my tests to better cover these code paths. v2: - Changed locking specification to avoid problems with a cross-driver ww locking, like was suggested by Christian König. Now the attach/detach callbacks are invoked without the held lock and exporter should take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (9): dma-buf: Add _unlocked postfix to function names dma-buf: Add locked variant of dma_buf_vmap/vunmap() drm/gem: Take reservation lock for vmap/vunmap operations dma-buf: Move dma_buf_vmap/vunmap_unlocked() to dynamic locking specification dma-buf: Move dma_buf_mmap_unlocked() to dynamic locking specification dma-buf: Move dma-buf attachment to dynamic locking specification dma-buf: Document dynamic locking convention media: videobuf2: Stop using internal dma-buf lock dma-buf: Remove internal lock Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c | 276 ++++++++++++++---- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/armada/armada_gem.c | 14 +- drivers/gpu/drm/drm_client.c | 4 +- drivers/gpu/drm/drm_gem.c | 24 ++ drivers/gpu/drm/drm_gem_dma_helper.c | 6 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_gem_ttm_helper.c | 9 +- drivers/gpu/drm/drm_prime.c | 12 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 + .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 20 +- drivers/gpu/drm/lima/lima_sched.c | 4 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 +- drivers/gpu/drm/panfrost/panfrost_dump.c | 4 +- drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 6 +- drivers/gpu/drm/qxl/qxl_object.c | 17 +- drivers/gpu/drm/qxl/qxl_prime.c | 4 +- drivers/gpu/drm/tegra/gem.c | 27 +- drivers/infiniband/core/umem_dmabuf.c | 11 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 23 +- .../common/videobuf2/videobuf2-vmalloc.c | 17 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 12 +- drivers/misc/fastrpc.c | 12 +- drivers/xen/gntdev-dmabuf.c | 14 +- include/drm/drm_gem.h | 3 + include/linux/dma-buf.h | 57 ++-- 32 files changed, 410 insertions(+), 242 deletions(-) -- 2.37.2

2 years, 4 months

[PATCH AUTOSEL 5.4 03/12] drm/gem: Fix GEM handle release errors

by Sasha Levin

From: Jeffy Chen <jeffy.chen(a)rock-chips.com> [ Upstream commit ea2aa97ca37a9044ade001aef71dbc06318e8d44 ] Currently we are assuming a one to one mapping between dmabuf and GEM handle when releasing GEM handles. But that is not always true, since we would create extra handles for the GEM obj in cases like gem_open() and getfb{,2}(). A similar issue was reported at: https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/ Another problem is that the imported dmabuf might not always have gem_obj->dma_buf set, which would cause leaks in drm_gem_remove_prime_handles(). Let's fix these for now by using handle to find the exact map to remove. Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220819072834.17888-1-jeffy.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_gem.c | 17 +---------------- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 20 ++++++++++++-------- 3 files changed, 15 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 25a2d80287d67..d6a72f3cb1fbd 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -167,21 +167,6 @@ void drm_gem_private_object_init(struct drm_device *dev, } EXPORT_SYMBOL(drm_gem_private_object_init); -static void -drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp) -{ - /* - * Note: obj->dma_buf can't disappear as long as we still hold a - * handle reference in obj->handle_count. - */ - mutex_lock(&filp->prime.lock); - if (obj->dma_buf) { - drm_prime_remove_buf_handle_locked(&filp->prime, - obj->dma_buf); - } - mutex_unlock(&filp->prime.lock); -} - /** * drm_gem_object_handle_free - release resources bound to userspace handles * @obj: GEM object to clean up. @@ -255,7 +240,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) else if (dev->driver->gem_close_object) dev->driver->gem_close_object(obj, file_priv); - drm_gem_remove_prime_handles(obj, file_priv); + drm_prime_remove_buf_handle(&file_priv->prime, id); drm_vma_node_revoke(&obj->vma_node, file_priv); drm_gem_object_handle_put_unlocked(obj); diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 51a2055c8f18a..41a9a9bae5848 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -59,8 +59,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data, void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv); void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv); -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf); +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle); /* drm_drv.c */ struct drm_minor *drm_minor_acquire(unsigned int minor_id); diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 0a2316e0e8121..6b7cf0170f9d1 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -187,29 +187,33 @@ static int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpri return -ENOENT; } -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf) +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle) { struct rb_node *rb; - rb = prime_fpriv->dmabufs.rb_node; + mutex_lock(&prime_fpriv->lock); + + rb = prime_fpriv->handles.rb_node; while (rb) { struct drm_prime_member *member; - member = rb_entry(rb, struct drm_prime_member, dmabuf_rb); - if (member->dma_buf == dma_buf) { + member = rb_entry(rb, struct drm_prime_member, handle_rb); + if (member->handle == handle) { rb_erase(&member->handle_rb, &prime_fpriv->handles); rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs); - dma_buf_put(dma_buf); + dma_buf_put(member->dma_buf); kfree(member); - return; - } else if (member->dma_buf < dma_buf) { + break; + } else if (member->handle < handle) { rb = rb->rb_right; } else { rb = rb->rb_left; } } + + mutex_unlock(&prime_fpriv->lock); } void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv) -- 2.35.1

2 years, 4 months

[PATCH AUTOSEL 5.10 04/16] drm/gem: Fix GEM handle release errors

by Sasha Levin

From: Jeffy Chen <jeffy.chen(a)rock-chips.com> [ Upstream commit ea2aa97ca37a9044ade001aef71dbc06318e8d44 ] Currently we are assuming a one to one mapping between dmabuf and GEM handle when releasing GEM handles. But that is not always true, since we would create extra handles for the GEM obj in cases like gem_open() and getfb{,2}(). A similar issue was reported at: https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/ Another problem is that the imported dmabuf might not always have gem_obj->dma_buf set, which would cause leaks in drm_gem_remove_prime_handles(). Let's fix these for now by using handle to find the exact map to remove. Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220819072834.17888-1-jeffy.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_gem.c | 17 +---------------- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 20 ++++++++++++-------- 3 files changed, 15 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 5979af230eda0..8b30e8d83fbcf 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -166,21 +166,6 @@ void drm_gem_private_object_init(struct drm_device *dev, } EXPORT_SYMBOL(drm_gem_private_object_init); -static void -drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp) -{ - /* - * Note: obj->dma_buf can't disappear as long as we still hold a - * handle reference in obj->handle_count. - */ - mutex_lock(&filp->prime.lock); - if (obj->dma_buf) { - drm_prime_remove_buf_handle_locked(&filp->prime, - obj->dma_buf); - } - mutex_unlock(&filp->prime.lock); -} - /** * drm_gem_object_handle_free - release resources bound to userspace handles * @obj: GEM object to clean up. @@ -254,7 +239,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) else if (dev->driver->gem_close_object) dev->driver->gem_close_object(obj, file_priv); - drm_gem_remove_prime_handles(obj, file_priv); + drm_prime_remove_buf_handle(&file_priv->prime, id); drm_vma_node_revoke(&obj->vma_node, file_priv); drm_gem_object_handle_put_unlocked(obj); diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index b65865c630b0a..f80e0f28087d1 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -86,8 +86,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data, void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv); void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv); -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf); +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle); /* drm_drv.c */ struct drm_minor *drm_minor_acquire(unsigned int minor_id); diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 9f955f2010c25..825499ea3ff59 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -187,29 +187,33 @@ static int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpri return -ENOENT; } -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf) +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle) { struct rb_node *rb; - rb = prime_fpriv->dmabufs.rb_node; + mutex_lock(&prime_fpriv->lock); + + rb = prime_fpriv->handles.rb_node; while (rb) { struct drm_prime_member *member; - member = rb_entry(rb, struct drm_prime_member, dmabuf_rb); - if (member->dma_buf == dma_buf) { + member = rb_entry(rb, struct drm_prime_member, handle_rb); + if (member->handle == handle) { rb_erase(&member->handle_rb, &prime_fpriv->handles); rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs); - dma_buf_put(dma_buf); + dma_buf_put(member->dma_buf); kfree(member); - return; - } else if (member->dma_buf < dma_buf) { + break; + } else if (member->handle < handle) { rb = rb->rb_right; } else { rb = rb->rb_left; } } + + mutex_unlock(&prime_fpriv->lock); } void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv) -- 2.35.1

2 years, 4 months

[PATCH AUTOSEL 5.15 04/23] drm/gem: Fix GEM handle release errors

by Sasha Levin

From: Jeffy Chen <jeffy.chen(a)rock-chips.com> [ Upstream commit ea2aa97ca37a9044ade001aef71dbc06318e8d44 ] Currently we are assuming a one to one mapping between dmabuf and GEM handle when releasing GEM handles. But that is not always true, since we would create extra handles for the GEM obj in cases like gem_open() and getfb{,2}(). A similar issue was reported at: https://lore.kernel.org/all/20211105083308.392156-1-jay.xu@rock-chips.com/ Another problem is that the imported dmabuf might not always have gem_obj->dma_buf set, which would cause leaks in drm_gem_remove_prime_handles(). Let's fix these for now by using handle to find the exact map to remove. Signed-off-by: Jeffy Chen <jeffy.chen(a)rock-chips.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220819072834.17888-1-jeffy.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_gem.c | 17 +---------------- drivers/gpu/drm/drm_internal.h | 4 ++-- drivers/gpu/drm/drm_prime.c | 20 ++++++++++++-------- 3 files changed, 15 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 6410563a9cb6f..dbd19a34b517b 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -167,21 +167,6 @@ void drm_gem_private_object_init(struct drm_device *dev, } EXPORT_SYMBOL(drm_gem_private_object_init); -static void -drm_gem_remove_prime_handles(struct drm_gem_object *obj, struct drm_file *filp) -{ - /* - * Note: obj->dma_buf can't disappear as long as we still hold a - * handle reference in obj->handle_count. - */ - mutex_lock(&filp->prime.lock); - if (obj->dma_buf) { - drm_prime_remove_buf_handle_locked(&filp->prime, - obj->dma_buf); - } - mutex_unlock(&filp->prime.lock); -} - /** * drm_gem_object_handle_free - release resources bound to userspace handles * @obj: GEM object to clean up. @@ -252,7 +237,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) if (obj->funcs->close) obj->funcs->close(obj, file_priv); - drm_gem_remove_prime_handles(obj, file_priv); + drm_prime_remove_buf_handle(&file_priv->prime, id); drm_vma_node_revoke(&obj->vma_node, file_priv); drm_gem_object_handle_put_unlocked(obj); diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index 17f3548c8ed25..d05e6a5b66873 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -74,8 +74,8 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data, void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv); void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv); -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf); +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle); /* drm_drv.c */ struct drm_minor *drm_minor_acquire(unsigned int minor_id); diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index d6c7f4f9a7a29..a350310b65d89 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -187,29 +187,33 @@ static int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpri return -ENOENT; } -void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private *prime_fpriv, - struct dma_buf *dma_buf) +void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, + uint32_t handle) { struct rb_node *rb; - rb = prime_fpriv->dmabufs.rb_node; + mutex_lock(&prime_fpriv->lock); + + rb = prime_fpriv->handles.rb_node; while (rb) { struct drm_prime_member *member; - member = rb_entry(rb, struct drm_prime_member, dmabuf_rb); - if (member->dma_buf == dma_buf) { + member = rb_entry(rb, struct drm_prime_member, handle_rb); + if (member->handle == handle) { rb_erase(&member->handle_rb, &prime_fpriv->handles); rb_erase(&member->dmabuf_rb, &prime_fpriv->dmabufs); - dma_buf_put(dma_buf); + dma_buf_put(member->dma_buf); kfree(member); - return; - } else if (member->dma_buf < dma_buf) { + break; + } else if (member->handle < handle) { rb = rb->rb_right; } else { rb = rb->rb_left; } } + + mutex_unlock(&prime_fpriv->lock); } void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv) -- 2.35.1

2 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig