diff options
| author | Junrui Luo <moonafterrain@outlook.com> | 2026-09-15 15:39:10 +0800 |
|---|---|---|
| committer | Dmitry Osipenko <dmitry.osipenko@collabora.com> | 2026-09-20 20:48:51 +0300 |
| commit | 36570ef2244cc4d7563b1f0157bc0f032498638c (patch) | |
| tree | b4f43d1019320e23266b7c3b6bc970ce7fd549c5 /tools/perf/scripts/python/stackcollapse.py | |
| parent | b74aad23d99b279bb34d135795f39a6d8ecdc075 (diff) | |
| download | linux-next-36570ef2244cc4d7563b1f0157bc0f032498638c.tar.gz linux-next-36570ef2244cc4d7563b1f0157bc0f032498638c.zip | |
drm/virtio: fix object leak when drm_gem_handle_create() fails
virtio_gpu_gem_create() owns the reference taken by
virtio_gpu_object_create(). On the drm_gem_handle_create() error path it
calls drm_gem_object_release() instead of dropping that reference.
drm_gem_object_release() is the inverse of drm_gem_object_init() and does
not touch the reference count or call obj->funcs->free(), so it is only
correct as the last step of a destructor, as in
virtio_gpu_cleanup_object(). Using it here leaves the bo at refcount 1
with no remaining reference, so virtio_gpu_free_object() never runs and
the shmem pages, sg table and virtio_gpu_object are leaked. Since
virtio_gpu_object_create() has already set bo->created,
VIRTIO_GPU_CMD_RESOURCE_UNREF is not queued either, leaking the host-side
resource and the resource id.
drm_gem_handle_create_tail() drops the handle reference on all of its
internal error paths, so the caller only has to drop its own. Use
drm_gem_object_put(), matching the success path below.
Fixes: dc5698e80cf7 ("Add virtio gpu driver.")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patch.msgid.link/20260915-fixes-v2-1-a0d799e4db66@outlook.com
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions
