search for: virtio_gpu_array_put_free_delay

...void virtio_gpu_array_unlock_resv(struct virtio_gpu_object_array *objs); > void virtio_gpu_array_add_fence(struct virtio_gpu_object_array *objs, > struct dma_fence *fence); > void virtio_gpu_array_put_free(struct virtio_gpu_object_array *objs); > +void virtio_gpu_array_put_free_delayed(struct virtio_gpu_device *vgdev, > + struct virtio_gpu_object_array *objs); > +void virtio_gpu_array_put_free_work(struct work_struct *work); > > /* virtio vg */ > int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev); > diff --git a/...

...Yes, it can happen, for example when flushing dumb buffers. But I don't think we leak in this case. The code paths which don't need a fence also do not call virtio_gpu_array_lock_resv(), so things are balanced. The actual release of the objs happens in virtio_gpu_dequeue_ctrl_func() via virtio_gpu_array_put_free_delayed(). cheers, Gerd

Only call virtio_gpu_array_add_fence if we actually have a fence. Fixes: da758d51968a ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing") Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c

Only call virtio_gpu_array_add_fence if we actually have a fence. Fixes: da758d51968a ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing") Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c