Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

18 participants
7031 discussions

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

by Daniel Vetter

On Fri, Jan 31, 2020 at 11:28 PM syzbot <syzbot+0dc4444774d419e916c8(a)syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit: 39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=179465bee00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=2646535f8818ae25 > dashboard link: https://syzkaller.appspot.com/bug?extid=0dc4444774d419e916c8 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16251279e00000 > > The bug was bisected to: > > commit 7611750784664db46d0db95631e322aeb263dde7 > Author: Alex Deucher <alexander.deucher(a)amd.com> > Date: Wed Jun 21 16:31:41 2017 +0000 > > drm/amdgpu: use kernel is_power_of_2 rather than local version > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11628df1e00000 > final crash: https://syzkaller.appspot.com/x/report.txt?x=13628df1e00000 > console output: https://syzkaller.appspot.com/x/log.txt?x=15628df1e00000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+0dc4444774d419e916c8(a)syzkaller.appspotmail.com > Fixes: 761175078466 ("drm/amdgpu: use kernel is_power_of_2 rather than local version") Aside: This bisect line is complete nonsense ... I'm kinda at the point where I'm assuming that syzbot bisect results are garbage, which is maybe not what we want. I guess much stricter filtering for noise is needed, dunno. -Danile > > ================================================================== > BUG: KASAN: use-after-free in vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221 > Read of size 8 at addr ffff88809fa67908 by task syz-executor.0/14871 > > CPU: 0 PID: 14871 Comm: syz-executor.0 Not tainted 5.5.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x197/0x210 lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 > __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506 > kasan_report+0x12/0x20 mm/kasan/common.c:639 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 > vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221 > drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100 > drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786 > drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886 > vfs_ioctl fs/ioctl.c:47 [inline] > ksys_ioctl+0x123/0x180 fs/ioctl.c:747 > __do_sys_ioctl fs/ioctl.c:756 [inline] > __se_sys_ioctl fs/ioctl.c:754 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x45b349 > Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:00007f871af46c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 00007f871af476d4 RCX: 000000000045b349 > RDX: 0000000020000180 RSI: 00000000c02064b2 RDI: 0000000000000003 > RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff > R13: 0000000000000285 R14: 00000000004d14d0 R15: 000000000075bf2c > > Allocated by task 14871: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > __kasan_kmalloc mm/kasan/common.c:513 [inline] > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486 > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527 > kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3551 > kmalloc include/linux/slab.h:556 [inline] > kzalloc include/linux/slab.h:670 [inline] > __vgem_gem_create+0x49/0x100 drivers/gpu/drm/vgem/vgem_drv.c:165 > vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:194 [inline] > vgem_gem_dumb_create+0xd7/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217 > drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100 > drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786 > drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886 > vfs_ioctl fs/ioctl.c:47 [inline] > ksys_ioctl+0x123/0x180 fs/ioctl.c:747 > __do_sys_ioctl fs/ioctl.c:756 [inline] > __se_sys_ioctl fs/ioctl.c:754 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Freed by task 14871: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > kasan_set_free_info mm/kasan/common.c:335 [inline] > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474 > kasan_slab_free+0xe/0x10 mm/kasan/common.c:483 > __cache_free mm/slab.c:3426 [inline] > kfree+0x10a/0x2c0 mm/slab.c:3757 > vgem_gem_free_object+0xbe/0xe0 drivers/gpu/drm/vgem/vgem_drv.c:68 > drm_gem_object_free+0x100/0x220 drivers/gpu/drm/drm_gem.c:983 > kref_put include/linux/kref.h:65 [inline] > drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline] > drm_gem_object_put_unlocked+0x196/0x1c0 drivers/gpu/drm/drm_gem.c:1002 > vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:199 [inline] > vgem_gem_dumb_create+0x115/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217 > drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100 > drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786 > drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886 > vfs_ioctl fs/ioctl.c:47 [inline] > ksys_ioctl+0x123/0x180 fs/ioctl.c:747 > __do_sys_ioctl fs/ioctl.c:756 [inline] > __se_sys_ioctl fs/ioctl.c:754 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > The buggy address belongs to the object at ffff88809fa67800 > which belongs to the cache kmalloc-1k of size 1024 > The buggy address is located 264 bytes inside of > 1024-byte region [ffff88809fa67800, ffff88809fa67c00) > The buggy address belongs to the page: > page:ffffea00027e99c0 refcount:1 mapcount:0 mapping:ffff8880aa400c40 index:0x0 > raw: 00fffe0000000200 ffffea0002293548 ffffea00023e1f08 ffff8880aa400c40 > raw: 0000000000000000 ffff88809fa67000 0000000100000002 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff88809fa67800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88809fa67880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > >ffff88809fa67900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff88809fa67980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88809fa67a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== > > > --- > This bug 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 bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

6 years, 6 months

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

by Hillf Danton

Fri, 31 Jan 2020 14:28:10 -0800 (PST) > syzbot found the following crash on: > > HEAD commit: 39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=179465bee00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=2646535f8818ae25 > dashboard link: https://syzkaller.appspot.com/bug?extid=0dc4444774d419e916c8 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16251279e00000 > > The bug was bisected to: > > commit 7611750784664db46d0db95631e322aeb263dde7 > Author: Alex Deucher <alexander.deucher(a)amd.com> > Date: Wed Jun 21 16:31:41 2017 +0000 > > drm/amdgpu: use kernel is_power_of_2 rather than local version > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11628df1e00000 > final crash: https://syzkaller.appspot.com/x/report.txt?x=13628df1e00000 > console output: https://syzkaller.appspot.com/x/log.txt?x=15628df1e00000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+0dc4444774d419e916c8(a)syzkaller.appspotmail.com > Fixes: 761175078466 ("drm/amdgpu: use kernel is_power_of_2 rather than local version") > > ================================================================== > BUG: KASAN: use-after-free in vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221 > Read of size 8 at addr ffff88809fa67908 by task syz-executor.0/14871 > > CPU: 0 PID: 14871 Comm: syz-executor.0 Not tainted 5.5.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x197/0x210 lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 > __kasan_report.cold+0x1b/0x32 mm/kasan/report.c:506 > kasan_report+0x12/0x20 mm/kasan/common.c:639 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 > vgem_gem_dumb_create+0x238/0x250 drivers/gpu/drm/vgem/vgem_drv.c:221 > drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100 > drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786 > drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886 > vfs_ioctl fs/ioctl.c:47 [inline] > ksys_ioctl+0x123/0x180 fs/ioctl.c:747 > __do_sys_ioctl fs/ioctl.c:756 [inline] > __se_sys_ioctl fs/ioctl.c:754 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x45b349 > Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:00007f871af46c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 > RAX: ffffffffffffffda RBX: 00007f871af476d4 RCX: 000000000045b349 > RDX: 0000000020000180 RSI: 00000000c02064b2 RDI: 0000000000000003 > RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff > R13: 0000000000000285 R14: 00000000004d14d0 R15: 000000000075bf2c > > Allocated by task 14871: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > __kasan_kmalloc mm/kasan/common.c:513 [inline] > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486 > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527 > kmem_cache_alloc_trace+0x158/0x790 mm/slab.c:3551 > kmalloc include/linux/slab.h:556 [inline] > kzalloc include/linux/slab.h:670 [inline] > __vgem_gem_create+0x49/0x100 drivers/gpu/drm/vgem/vgem_drv.c:165 > vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:194 [inline] > vgem_gem_dumb_create+0xd7/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217 > drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100 > drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786 > drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886 > vfs_ioctl fs/ioctl.c:47 [inline] > ksys_ioctl+0x123/0x180 fs/ioctl.c:747 > __do_sys_ioctl fs/ioctl.c:756 [inline] > __se_sys_ioctl fs/ioctl.c:754 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Freed by task 14871: > save_stack+0x23/0x90 mm/kasan/common.c:72 > set_track mm/kasan/common.c:80 [inline] > kasan_set_free_info mm/kasan/common.c:335 [inline] > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474 > kasan_slab_free+0xe/0x10 mm/kasan/common.c:483 > __cache_free mm/slab.c:3426 [inline] > kfree+0x10a/0x2c0 mm/slab.c:3757 > vgem_gem_free_object+0xbe/0xe0 drivers/gpu/drm/vgem/vgem_drv.c:68 > drm_gem_object_free+0x100/0x220 drivers/gpu/drm/drm_gem.c:983 > kref_put include/linux/kref.h:65 [inline] > drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline] > drm_gem_object_put_unlocked+0x196/0x1c0 drivers/gpu/drm/drm_gem.c:1002 > vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:199 [inline] > vgem_gem_dumb_create+0x115/0x250 drivers/gpu/drm/vgem/vgem_drv.c:217 > drm_mode_create_dumb+0x282/0x310 drivers/gpu/drm/drm_dumb_buffers.c:94 > drm_mode_create_dumb_ioctl+0x26/0x30 drivers/gpu/drm/drm_dumb_buffers.c:100 > drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786 > drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886 > vfs_ioctl fs/ioctl.c:47 [inline] > ksys_ioctl+0x123/0x180 fs/ioctl.c:747 > __do_sys_ioctl fs/ioctl.c:756 [inline] > __se_sys_ioctl fs/ioctl.c:754 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > The buggy address belongs to the object at ffff88809fa67800 > which belongs to the cache kmalloc-1k of size 1024 > The buggy address is located 264 bytes inside of > 1024-byte region [ffff88809fa67800, ffff88809fa67c00) > The buggy address belongs to the page: > page:ffffea00027e99c0 refcount:1 mapcount:0 mapping:ffff8880aa400c40 index:0x0 > raw: 00fffe0000000200 ffffea0002293548 ffffea00023e1f08 ffff8880aa400c40 > raw: 0000000000000000 ffff88809fa67000 0000000100000002 0000000000000000 > page dumped because: kasan: bad access detected > > Memory state around the buggy address: > ffff88809fa67800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88809fa67880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > >ffff88809fa67900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ^ > ffff88809fa67980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88809fa67a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ================================================================== Release obj in error path. --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -196,10 +196,10 @@ static struct drm_gem_object *vgem_gem_c return ERR_CAST(obj); ret = drm_gem_handle_create(file, &obj->base, handle); - drm_gem_object_put_unlocked(&obj->base); - if (ret) + if (ret) { + drm_gem_object_put_unlocked(&obj->base); return ERR_PTR(ret); - + } return &obj->base; }

6 years, 6 months

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

by Dan Carpenter

I don't totally understand the stack trace but I do see a double free bug. drivers/gpu/drm/vgem/vgem_drv.c 186 static struct drm_gem_object *vgem_gem_create(struct drm_device *dev, 187 struct drm_file *file, 188 unsigned int *handle, 189 unsigned long size) 190 { 191 struct drm_vgem_gem_object *obj; 192 int ret; 193 194 obj = __vgem_gem_create(dev, size); obj->base.handle_count is zero. 195 if (IS_ERR(obj)) 196 return ERR_CAST(obj); 197 198 ret = drm_gem_handle_create(file, &obj->base, handle); We bump it +1 and then the error handling calls drm_gem_object_handle_put_unlocked(obj); which calls drm_gem_object_put_unlocked(); which frees obj. 199 drm_gem_object_put_unlocked(&obj->base); So this is a double free. Could someone check my thinking and send a patch? It's just a one liner. Otherwise I can send it on Monday. 200 if (ret) 201 return ERR_PTR(ret); 202 203 return &obj->base; 204 } regards, dan carpenter

6 years, 6 months

[PATCH] dma-buf: fix locking in sync_print_obj()

by Dan Carpenter

This is always called with IRQs disabled and we don't actually want to enable IRQs at the end. Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/dma-buf/sync_debug.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c index 101394f16930..952331344b1c 100644 --- a/drivers/dma-buf/sync_debug.c +++ b/drivers/dma-buf/sync_debug.c @@ -107,15 +107,16 @@ static void sync_print_fence(struct seq_file *s, static void sync_print_obj(struct seq_file *s, struct sync_timeline *obj) { struct list_head *pos; + unsigned long flags; seq_printf(s, "%s: %d\n", obj->name, obj->value); - spin_lock_irq(&obj->lock); + spin_lock_irqsave(&obj->lock, flags); list_for_each(pos, &obj->pt_list) { struct sync_pt *pt = container_of(pos, struct sync_pt, link); sync_print_fence(s, &pt->base, false); } - spin_unlock_irq(&obj->lock); + spin_unlock_irqrestore(&obj->lock, flags); } static void sync_print_sync_file(struct seq_file *s, -- 2.11.0

6 years, 6 months

[PATCH] dma-heap: Make the symbol 'dma_heap_ioctl_cmds' static

by Sumit Semwal

From: zhong jiang <zhongjiang(a)huawei.com> Fix the following sparse warning. drivers/dma-buf/dma-heap.c:109:14: warning: symbol 'dma_heap_ioctl_cmds' was not declared. Should it be static? Acked-by: Andrew F. Davis <afd(a)ti.com> Acked-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: zhong jiang <zhongjiang(a)huawei.com> Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> [sumits: rebased over IOCTL rename patches] --- drivers/dma-buf/dma-heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index 1886aee46131..afd22c9dbdcf 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -106,7 +106,7 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data) return 0; } -unsigned int dma_heap_ioctl_cmds[] = { +static unsigned int dma_heap_ioctl_cmds[] = { DMA_HEAP_IOCTL_ALLOC, }; -- 2.18.0

6 years, 7 months

[PATCH][next] dma-buf: fix resource leak on -ENOTTY error return path

by Colin King

From: Colin Ian King <colin.king(a)canonical.com> The -ENOTTY error return path does not free the allocated kdata as it returns directly. Fix this by returning via the error handling label err. Addresses-Coverity: ("Resource leak") Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/dma-buf/dma-heap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c index 4f04d104ae61..80f2f5eac1e4 100644 --- a/drivers/dma-buf/dma-heap.c +++ b/drivers/dma-buf/dma-heap.c @@ -157,7 +157,8 @@ static long dma_heap_ioctl(struct file *file, unsigned int ucmd, ret = dma_heap_ioctl_allocate(file, kdata); break; default: - return -ENOTTY; + ret = -ENOTTY; + goto err; } if (copy_to_user((void __user *)arg, kdata, out_size) != 0) -- 2.24.0

6 years, 7 months

[PATCH] MAINTAINERS: Match on dma_buf|fence|resv anywhere

by Daniel Vetter

I've spent a bit too much time reviewing all kinds of users all over the kernel for this buffer sharing infrastructure. And some of it is at least questionable. Make sure we at least see when this stuff flies by. Acked-by: Dave Airlie <airlied(a)gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Rob Herring <robh(a)kernel.org> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 375dbea8bc88..c1e3da2c1947 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4941,6 +4941,7 @@ F: include/linux/dma-buf* F: include/linux/reservation.h F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst +K: dma_(buf|fence|resv) T: git git://anongit.freedesktop.org/drm/drm-misc DMA GENERIC OFFLOAD ENGINE SUBSYSTEM -- 2.24.0

6 years, 8 months

[PATCH] udmabuf: Remove deleted map/unmap handlers.

by Maarten Lankhorst

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(a)linux.intel.com> Fixes: 7f0de8d80816 ("dma-buf: Drop dma_buf_k(un)map") Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: dri-devel(a)lists.freedesktop.org --- drivers/dma-buf/udmabuf.c | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 9635897458a0..9de539c1def4 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -93,26 +93,10 @@ static void release_udmabuf(struct dma_buf *buf) kfree(ubuf); } -static void *kmap_udmabuf(struct dma_buf *buf, unsigned long page_num) -{ - struct udmabuf *ubuf = buf->priv; - struct page *page = ubuf->pages[page_num]; - - return kmap(page); -} - -static void kunmap_udmabuf(struct dma_buf *buf, unsigned long page_num, - void *vaddr) -{ - kunmap(vaddr); -} - static const struct dma_buf_ops udmabuf_ops = { .map_dma_buf = map_udmabuf, .unmap_dma_buf = unmap_udmabuf, .release = release_udmabuf, - .map = kmap_udmabuf, - .unmap = kunmap_udmabuf, .mmap = mmap_udmabuf, }; -- 2.24.0

6 years, 8 months

[PATCH 15/15] dma-buf: Remove kernel map/unmap hooks

by Daniel Vetter

All implementations are gone now. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- include/linux/dma-buf.h | 25 ------------------------- 1 file changed, 25 deletions(-) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 7feb9c3805ae..abf5459a5b9d 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -249,31 +249,6 @@ struct dma_buf_ops { */ int (*mmap)(struct dma_buf *, struct vm_area_struct *vma); - /** - * @map: - * - * Maps a page from the buffer into kernel address space. The page is - * specified by offset into the buffer in PAGE_SIZE units. - * - * This callback is optional. - * - * Returns: - * - * Virtual address pointer where requested page can be accessed. NULL - * on error or when this function is unimplemented by the exporter. - */ - void *(*map)(struct dma_buf *, unsigned long); - - /** - * @unmap: - * - * Unmaps a page from the buffer. Page offset and address pointer should - * be the same as the one passed to and returned by matching call to map. - * - * This callback is optional. - */ - void (*unmap)(struct dma_buf *, unsigned long, void *); - void *(*vmap)(struct dma_buf *); void (*vunmap)(struct dma_buf *, void *vaddr); }; -- 2.24.0

6 years, 8 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: Fix memory leak in sync_file_merge()

by Daniel Vetter

On Fri, Nov 22, 2019 at 04:09:55PM -0600, Navid Emamdoost wrote: > In the implementation of sync_file_merge() the allocated sync_file is > leaked if number of fences overflows. Release sync_file by goto err. > > Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct sync_file") > Signed-off-by: Navid Emamdoost <navid.emamdoost(a)gmail.com> Thanks for your patch, applied with a cc:stable. -Daniel > --- > drivers/dma-buf/sync_file.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > index 25c5c071645b..91185db9a952 100644 > --- a/drivers/dma-buf/sync_file.c > +++ b/drivers/dma-buf/sync_file.c > @@ -221,7 +221,7 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, > a_fences = get_fences(a, &a_num_fences); > b_fences = get_fences(b, &b_num_fences); > if (a_num_fences > INT_MAX - b_num_fences) > - return NULL; > + goto err; > > num_fences = a_num_fences + b_num_fences; > > -- > 2.17.1 > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

6 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig