Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

3 participants
2908 discussions

by Christian König

The basic idea stayed the same since the last version of those patches. The exporter can provide explicit pin/unpin functions and the importer a move_notify callback. This allows us to avoid pinning buffers while importers have a mapping for them. In difference to the last version the locking changes were separated from this patchset and committed to drm-misc-next. This allows drivers to implement the new locking semantics without the extra unpinned handling, but of course the changed locking semantics is still a prerequisite to the unpinned handling. The last time this set was send out the discussion ended by questioning if the move_notify callback was really the right approach of notifying the importers that a buffer is about to change its placement. A possible alternative would be to add a special crafted fence object instead. Let's discuss on the different approaches once more, Christian.

5 years, 4 months

RFC: Unpinned DMA-buf handling

by Christian König

Hi everyone, hopefully the last iteration of those patches. For now I've addressed the issue of unmapping imported BOs from the amdgpu page tables immediately by locking the page tables in place. For HMM handling we are getting the ability to invalidate BOs without locking the VM anyway, so this last TODO will probably go away rather soon. Place comment, Christian.

5 years, 4 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: Fix a typo in Kconfig

by Daniel Vetter

On Sun, Feb 16, 2020 at 12:47:08PM +0100, Christophe JAILLET wrote: > A 'h' ismissing in' syncronization' > > Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Applied, thanks for your patch. -Daniel > --- > drivers/dma-buf/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > index 0613bb7770f5..e7d820ce0724 100644 > --- a/drivers/dma-buf/Kconfig > +++ b/drivers/dma-buf/Kconfig > @@ -6,7 +6,7 @@ config SYNC_FILE > default n > select DMA_SHARED_BUFFER > ---help--- > - The Sync File Framework adds explicit syncronization via > + The Sync File Framework adds explicit synchronization via > userspace. It enables send/receive 'struct dma_fence' objects to/from > userspace via Sync File fds for synchronization between drivers via > userspace components. It has been ported from Android. > -- > 2.20.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

5 years, 4 months

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

by Rob Herring

On Mon, Feb 3, 2020 at 9:33 AM YueHaibing <yuehaibing(a)huawei.com> 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> > --- > drivers/gpu/drm/panfrost/panfrost_job.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) Applied to drm-misc-fixes. Rob

5 years, 4 months

[PATCH v2 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 1bc13f6b161b..d37ddd7644f6 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -281,8 +281,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 4e22c3914f94..87c439156151 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -545,22 +545,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, 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, @@ -1155,36 +1139,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, 4 months

[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, 4 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, 5 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, 5 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, 5 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, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig