From: Gerd Hoffmann <kraxel@redhat.com> To: dri-devel@lists.freedesktop.org, David Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com>, David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>, virtualization@lists.linux-foundation.org (open list:VIRTIO GPU DRIVER), linux-kernel@vger.kernel.org (open list) Subject: [PATCH] drm/virtio: do NOT reuse resource ids Date: Fri, 8 Feb 2019 15:04:09 +0100 [thread overview] Message-ID: <20190208140409.15280-1-kraxel@redhat.com> (raw) Bisected guest kernel changes crashing qemu. Landed at "6c1cd97bda drm/virtio: fix resource id handling". Looked again, and noticed we where not only leaking *some* ids, but *all* ids. The old code never ever called virtio_gpu_resource_id_put(). So, commit 6c1cd97bda effectively makes the linux kernel starting re-using IDs after releasing them, and apparently virglrenderer can't deal with that. Oops. This patch puts a temporary stopgap into place for the 5.0 release. Cc: David Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> --- Notes: Hi Dave, I'll be offline next week, so please commit to drm-next-fixes if you think this patch is acceptable. drivers/gpu/drm/virtio/virtgpu_object.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index f39a183d59..e7e9460350 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -28,10 +28,21 @@ static int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t *resid) { +#if 0 int handle = ida_alloc(&vgdev->resource_ida, GFP_KERNEL); if (handle < 0) return handle; +#else + static int handle; + + /* + * FIXME: dirty hack to avoid re-using IDs, virglrenderer + * can't deal with that. Needs fixing in virglrenderer, also + * should figure a better way to handle that in the guest. + */ + handle++; +#endif *resid = handle + 1; return 0; @@ -39,7 +50,9 @@ static int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, static void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id) { +#if 0 ida_free(&vgdev->resource_ida, id - 1); +#endif } static void virtio_gpu_ttm_bo_destroy(struct ttm_buffer_object *tbo) -- 2.9.3
WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com> To: dri-devel@lists.freedesktop.org, David Airlie <airlied@redhat.com> Cc: David Airlie <airlied@linux.ie>, open list <linux-kernel@vger.kernel.org>, Gerd Hoffmann <kraxel@redhat.com>, "open list:VIRTIO GPU DRIVER" <virtualization@lists.linux-foundation.org> Subject: [PATCH] drm/virtio: do NOT reuse resource ids Date: Fri, 8 Feb 2019 15:04:09 +0100 [thread overview] Message-ID: <20190208140409.15280-1-kraxel@redhat.com> (raw) Bisected guest kernel changes crashing qemu. Landed at "6c1cd97bda drm/virtio: fix resource id handling". Looked again, and noticed we where not only leaking *some* ids, but *all* ids. The old code never ever called virtio_gpu_resource_id_put(). So, commit 6c1cd97bda effectively makes the linux kernel starting re-using IDs after releasing them, and apparently virglrenderer can't deal with that. Oops. This patch puts a temporary stopgap into place for the 5.0 release. Cc: David Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> --- Notes: Hi Dave, I'll be offline next week, so please commit to drm-next-fixes if you think this patch is acceptable. drivers/gpu/drm/virtio/virtgpu_object.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index f39a183d59..e7e9460350 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -28,10 +28,21 @@ static int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t *resid) { +#if 0 int handle = ida_alloc(&vgdev->resource_ida, GFP_KERNEL); if (handle < 0) return handle; +#else + static int handle; + + /* + * FIXME: dirty hack to avoid re-using IDs, virglrenderer + * can't deal with that. Needs fixing in virglrenderer, also + * should figure a better way to handle that in the guest. + */ + handle++; +#endif *resid = handle + 1; return 0; @@ -39,7 +50,9 @@ static int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, static void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id) { +#if 0 ida_free(&vgdev->resource_ida, id - 1); +#endif } static void virtio_gpu_ttm_bo_destroy(struct ttm_buffer_object *tbo) -- 2.9.3 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2019-02-08 14:04 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-08 14:04 Gerd Hoffmann [this message] 2019-02-08 14:04 ` [PATCH] drm/virtio: do NOT reuse resource ids Gerd Hoffmann -- strict thread matches above, loose matches on Subject: below -- 2019-02-08 14:04 Gerd Hoffmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190208140409.15280-1-kraxel@redhat.com \ --to=kraxel@redhat.com \ --cc=airlied@linux.ie \ --cc=airlied@redhat.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.