Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

4 participants
3113 discussions

[PATCH 3/4] drm/virtio: move mapping teardown to virtio_gpu_cleanup_object()

by Gerd Hoffmann

Stop sending DETACH_BACKING commands, that will happening anyway when releasing resources via UNREF. Handle guest-side cleanup in virtio_gpu_cleanup_object(), called when the host finished processing the UNREF command. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 -- drivers/gpu/drm/virtio/virtgpu_object.c | 14 ++++++-- drivers/gpu/drm/virtio/virtgpu_vq.c | 46 ------------------------- 3 files changed, 12 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 372dd248cf02..15fb3c12f22f 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -280,8 +280,6 @@ void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device *vgdev, int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev, struct virtio_gpu_object *obj, struct virtio_gpu_fence *fence); -void virtio_gpu_object_detach(struct virtio_gpu_device *vgdev, - struct virtio_gpu_object *obj); int virtio_gpu_attach_status_page(struct virtio_gpu_device *vgdev); int virtio_gpu_detach_status_page(struct virtio_gpu_device *vgdev); void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 28a161af7503..bce2b3d843fe 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -23,6 +23,7 @@ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ +#include <linux/dma-mapping.h> #include <linux/moduleparam.h> #include "virtgpu_drv.h" @@ -65,6 +66,17 @@ void virtio_gpu_cleanup_object(struct virtio_gpu_object *bo) { struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private; + if (bo->pages) { + if (bo->mapped) { + dma_unmap_sg(vgdev->vdev->dev.parent, + bo->pages->sgl, bo->mapped, + DMA_TO_DEVICE); + bo->mapped = 0; + } + sg_free_table(bo->pages); + bo->pages = NULL; + drm_gem_shmem_unpin(&bo->base.base); + } virtio_gpu_resource_id_put(vgdev, bo->hw_res_handle); drm_gem_shmem_free_object(&bo->base.base); } @@ -74,8 +86,6 @@ static void virtio_gpu_free_object(struct drm_gem_object *obj) struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj); struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private; - if (bo->pages) - virtio_gpu_object_detach(vgdev, bo); if (bo->created) { virtio_gpu_cmd_unref_resource(vgdev, bo); /* completion handler calls virtio_gpu_cleanup_object() */ diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 6e8097e4c214..e258186bedb2 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -538,22 +538,6 @@ void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device *vgdev, virtio_gpu_queue_ctrl_buffer(vgdev, vbuf); } -static void virtio_gpu_cmd_resource_inval_backing(struct virtio_gpu_device *vgdev, - uint32_t resource_id, - struct virtio_gpu_fence *fence) -{ - struct virtio_gpu_resource_detach_backing *cmd_p; - struct virtio_gpu_vbuffer *vbuf; - - cmd_p = virtio_gpu_alloc_cmd(vgdev, &vbuf, sizeof(*cmd_p)); - memset(cmd_p, 0, sizeof(*cmd_p)); - - cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING); - cmd_p->resource_id = cpu_to_le32(resource_id); - - virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, &cmd_p->hdr, fence); -} - void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device *vgdev, uint32_t scanout_id, uint32_t resource_id, uint32_t width, uint32_t height, @@ -1148,36 +1132,6 @@ int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev, return 0; } -void virtio_gpu_object_detach(struct virtio_gpu_device *vgdev, - struct virtio_gpu_object *obj) -{ - bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev); - - if (WARN_ON_ONCE(!obj->pages)) - return; - - if (use_dma_api && obj->mapped) { - struct virtio_gpu_fence *fence = virtio_gpu_fence_alloc(vgdev); - /* detach backing and wait for the host process it ... */ - virtio_gpu_cmd_resource_inval_backing(vgdev, obj->hw_res_handle, fence); - dma_fence_wait(&fence->f, true); - dma_fence_put(&fence->f); - - /* ... then tear down iommu mappings */ - dma_unmap_sg(vgdev->vdev->dev.parent, - obj->pages->sgl, obj->mapped, - DMA_TO_DEVICE); - obj->mapped = 0; - } else { - virtio_gpu_cmd_resource_inval_backing(vgdev, obj->hw_res_handle, NULL); - } - - sg_free_table(obj->pages); - obj->pages = NULL; - - drm_gem_shmem_unpin(&obj->base.base); -} - void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, struct virtio_gpu_output *output) { -- 2.18.1

5 years, 9 months

Re: [Linaro-mm-sig] [PATCH -next] drm/panfrost: Remove set but not used variable 'bo'

by Steven Price

On Mon, Feb 03, 2020 at 03:27:24PM +0000, YueHaibing wrote: > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_cleanup': > drivers/gpu/drm/panfrost/panfrost_job.c:278:31: warning: > variable 'bo' set but not used [-Wunused-but-set-variable] > > commit bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept") > involved this unused variable. > > Reported-by: Hulk Robot <hulkci(a)huawei.com> > Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> I'm not sure how I didn't spot that before! Thanks for fixing it. Note commit bdefca2d8dc0 is actually in v5.5 and not (yet) in drm-misc-next. Reviewed-by: Steven Price <steven.price(a)arm.com> > --- > drivers/gpu/drm/panfrost/panfrost_job.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c > index 7c36ec675b73..ccb8546a9342 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_job.c > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > @@ -275,12 +275,8 @@ static void panfrost_job_cleanup(struct kref *ref) > } > > if (job->bos) { > - struct panfrost_gem_object *bo; > - > - for (i = 0; i < job->bo_count; i++) { > - bo = to_panfrost_bo(job->bos[i]); > + for (i = 0; i < job->bo_count; i++) > drm_gem_object_put_unlocked(job->bos[i]); > - } > > kvfree(job->bos); > } > > >

5 years, 9 months

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

5 years, 9 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; }

5 years, 9 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

5 years, 9 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

5 years, 9 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

5 years, 10 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

5 years, 10 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

5 years, 10 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

5 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig