search for: free_vbufs

...pu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 2f76673..4e66e35 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -178,9 +178,7 @@ struct virtio_gpu_device { struct virtio_gpu_queue ctrlq; struct virtio_gpu_queue cursorq; - struct list_head free_vbufs; - spinlock_t free_vbufs_lock; - void *vbufs; + struct kmem_cache *vbufs; bool vqs_ready; struct idr resource_idr; diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 43ea0dc..472e349 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/d...

...pu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 2f76673..4e66e35 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -178,9 +178,7 @@ struct virtio_gpu_device { struct virtio_gpu_queue ctrlq; struct virtio_gpu_queue cursorq; - struct list_head free_vbufs; - spinlock_t free_vbufs_lock; - void *vbufs; + struct kmem_cache *vbufs; bool vqs_ready; struct idr resource_idr; diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 43ea0dc..472e349 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/d...

On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > Hi, > > I can relatively easily reproduce this bug: > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > ------------[ cut here ]------------ > kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! > invalid opcode: 0000 [#1] PREEMPT SMP KASAN > Modules linked in: > CPU: 1 PID: 355 Comm: kworker/1:2 Not tainted 4.9.0-rc2-next-20161028+ #32 > Hardw...

Hi, I can relatively easily reproduce this bug: BUG: 'list_empty(&vgdev->free_vbufs)' is true! ------------[ cut here ]------------ kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! invalid opcode: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 1 PID: 355 Comm: kworker/1:2 Not tainted 4.9.0-rc2-next-20161028+ #32 Hardware name: QEMU Standard PC (i4...

Hi, I can relatively easily reproduce this bug: BUG: 'list_empty(&vgdev->free_vbufs)' is true! ------------[ cut here ]------------ kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! invalid opcode: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 1 PID: 355 Comm: kworker/1:2 Not tainted 4.9.0-rc2-next-20161028+ #32 Hardware name: QEMU Standard PC (i4...

...tgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index ff8de3d..6d4db2d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -162,6 +162,7 @@ struct virtio_gpu_device { struct virtio_gpu_queue ctrlq; struct virtio_gpu_queue cursorq; struct list_head free_vbufs; + spinlock_t free_vbufs_lock; void *vbufs; bool vqs_ready; diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index c506792..1698669f 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -79,6 +79,7 @@ int virtio_gp...

...tgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index ff8de3d..6d4db2d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -162,6 +162,7 @@ struct virtio_gpu_device { struct virtio_gpu_queue ctrlq; struct virtio_gpu_queue cursorq; struct list_head free_vbufs; + spinlock_t free_vbufs_lock; void *vbufs; bool vqs_ready; diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index c506792..1698669f 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -79,6 +79,7 @@ int virtio_gp...

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at some kind > of memory corruption. Looking carefully through the code I think it isn't impossible to trigger this, but you need for that: (1) command queue fu...

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at some kind > of memory corruption. Looking carefully through the code I think it isn't impossible to trigger this, but you need for that: (1) command queue fu...

...> How? Run dmesg -w in the qemu window (virtio_gpu) to see a lot of output. Run pps [1] without exit(0); on e.g. serial console. Wait a bit. The lot of output causes the BUG. [1] https://github.com/jirislaby/collected_sources/blob/master/pps.c >>> BUG: 'list_empty(&vgdev->free_vbufs)' is true! > >> The following might be helpful for debugging - if kernel still will >> not stop panicing, we are looking at some kind >> of memory corruption. > > Looking carefully through the code I think it isn't impossible to > trigger this, but you need f...

...tput. fbcon? Or xorg/wayland with terminal app? > Run pps [1] without exit(0); on e.g. serial console. > Wait a bit. The lot of output causes the BUG. > > [1] https://github.com/jirislaby/collected_sources/blob/master/pps.c > > >>> BUG: 'list_empty(&vgdev->free_vbufs)' is true! > > > >> The following might be helpful for debugging - if kernel still will > >> not stop panicing, we are looking at some kind > >> of memory corruption. > > > > Looking carefully through the code I think it isn't impossible to &gt...

...tput. fbcon? Or xorg/wayland with terminal app? > Run pps [1] without exit(0); on e.g. serial console. > Wait a bit. The lot of output causes the BUG. > > [1] https://github.com/jirislaby/collected_sources/blob/master/pps.c > > >>> BUG: 'list_empty(&vgdev->free_vbufs)' is true! > > > >> The following might be helpful for debugging - if kernel still will > >> not stop panicing, we are looking at some kind > >> of memory corruption. > > > > Looking carefully through the code I think it isn't impossible to &gt...

Hi, > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h > > @@ -120,9 +120,9 @@ struct virtio_gpu_vbuffer { > > > > char *resp_buf; > > int resp_size; > > - > > virtio_gpu_resp_cb resp_cb; > > > > + struct virtio_gpu_object_array *objs; > This can use a comment

On 11/15/2016, 09:46 AM, Gerd Hoffmann wrote: > On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: >> On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: >>> On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: >>>> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: >>>>> Hi, >>>>> >>>>> I can relatively easily

When virtio_gpu_free_vbufs exits due to list empty, it does not drop the free_vbufs lock that it took. list empty is not expected to happen anyway, but it can't hurt to fix this and drop the lock. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +++- 1 file change...

On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: > On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: > > On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > >> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > >>> Hi, > >>> > >>> I can relatively easily reproduce this bug: > > > > How? > > Run dmesg -w

On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: > On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: > > On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > >> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > >>> Hi, > >>> > >>> I can relatively easily reproduce this bug: > > > > How? > > Run dmesg -w

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Daniel Vetter

Use gem reservation helpers and direct reservation_object_* calls instead of ttm. v3: Also attach the array of gem objects to the virtio command buffer, so we can drop the object references in the completion callback. Needed because ttm fence helpers grab a reference for us, but gem helpers don't. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Acked-by: Daniel Vetter

...gt;config_changed_work); vgdev->vdev->config->reset(vgdev->vdev); vgdev->vdev->config->del_vqs(vgdev->vdev); +} + +void virtio_gpu_release(struct drm_device *dev) +{ + struct virtio_gpu_device *vgdev = dev->dev_private; virtio_gpu_modeset_fini(vgdev); virtio_gpu_free_vbufs(vgdev); diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index cc02fc4bab2a..cc674b45f904 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -330,6 +330,11 @@ static void virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_dev...