All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abhin Parekadan Jose <abhinjoses@gmail.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	David Airlie <airlied@redhat.com>
Cc: Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Simona Vetter <simona@ffwll.ch>,
	Dongwon Kim <dongwon.kim@intel.com>,
	dri-devel@lists.freedesktop.org, virtualization@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	syzbot+3590d97d8a586fa955c2@syzkaller.appspotmail.com,
	Abhin Parekadan Jose <abhinjoses@gmail.com>
Subject: [PATCH] drm/virtio: Destroy obj_restore_lock on the final drm_dev_put()
Date: Tue, 29 Sep 2026 07:07:14 +0000	[thread overview]
Message-ID: <20260929070714.169412-1-abhinjoses@gmail.com> (raw)

virtio_gpu_deinit() calls mutex_destroy() on obj_restore_lock, but
deinit runs from virtio_gpu_remove() at unbind or PCI remove, and GEM
objects can outlive that. An open /dev/fb0 keeps the fbdev buffer
alive, and the fbdev DRM client holds a drm_device reference. When the
fd is finally closed, the buffer is freed and takes the destroyed lock:

  fb_release()
    drm_fbdev_shmem_fb_destroy()
      drm_client_buffer_delete()
        virtio_gpu_free_object()
          virtio_gpu_remove_from_restore_list()
            mutex_lock(&vgdev->obj_restore_lock)

  DEBUG_LOCKS_WARN_ON(lock->magic != lock)
  WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0xf2c/0x12ec

virtio_gpu_deinit() should only do hardware teardown in this case
related virtio, its queues and others. Software state that GEM callbacks
still use belongs in virtio_gpu_release(), which runs on the final
drm_dev_put().

There are two equivalent ways to tie the mutex lifetime to the
drm_device:

 1) Move mutex_destroy() from virtio_gpu_deinit() to the end of
    virtio_gpu_release(). This is what this patch does. It is the
    smallest change and keeps the teardown next to the rest of the
    final-put software cleanup.

 2) Initialise the lock with drmm_mutex_init() (checking its return
    value) and drop mutex_destroy() from virtio_gpu_deinit(), so DRM's
    managed release destroys it. This also covers the virtio_gpu_init()
    error path, where release returns early because dev_private is
    NULL. Skipping mutex_destroy() there is harmless, since it only
    matters for mutex debugging.

Either fix removes the WARN. Option 1 is sent as the smaller change,
and option 2 can be done instead if preferred.

Reproduced on arm64 QEMU (-device virtio-gpu-pci) with DEBUG_MUTEXES
and PROVE_LOCKING: open /dev/fb0, write 1 to
/sys/bus/pci/devices/0000:00:01.0/remove, then close the fd. With this
patch the WARN is gone, and rebinding brings back /dev/fb0 and
/dev/dri/card0.

Fixes: 54a970048296 ("drm/virtio: Add support for saving and restoring virtio_gpu_objects")
Reported-by: syzbot+3590d97d8a586fa955c2@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3590d97d8a586fa955c2
Assisted-by: LLM
Signed-off-by: Abhin Parekadan Jose <abhinjoses@gmail.com>
---
 drivers/gpu/drm/virtio/virtgpu_kms.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 1d4d3bf46a20..0ec755c35050 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -354,7 +354,6 @@ void virtio_gpu_deinit(struct drm_device *dev)
 	virtio_reset_device(vgdev->vdev);
 	virtio_gpu_reclaim_vbufs(vgdev);
 	vgdev->vdev->config->del_vqs(vgdev->vdev);
-	mutex_destroy(&vgdev->obj_restore_lock);
 }
 
 void virtio_gpu_release(struct drm_device *dev)
@@ -370,6 +369,8 @@ void virtio_gpu_release(struct drm_device *dev)
 
 	if (vgdev->has_host_visible)
 		drm_mm_takedown(&vgdev->host_visible_mm);
+
+	mutex_destroy(&vgdev->obj_restore_lock);
 }
 
 int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file)

base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
-- 
2.51.1


             reply	other threads:[~2026-09-29  8:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29  7:07 Abhin Parekadan Jose [this message]
2026-09-29  7:16 ` [PATCH] drm/virtio: Destroy obj_restore_lock on the final drm_dev_put() sashiko-bot
2026-10-12  5:44 ` Abhin Parekadan Jose
2026-10-13 22:16   ` Dmitry Osipenko
2026-10-14 19:53     ` Abhin Parekadan Jose

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=20260929070714.169412-1-abhinjoses@gmail.com \
    --to=abhinjoses@gmail.com \
    --cc=airlied@redhat.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dongwon.kim@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gurchetansingh@chromium.org \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=simona@ffwll.ch \
    --cc=syzbot+3590d97d8a586fa955c2@syzkaller.appspotmail.com \
    --cc=tzimmermann@suse.de \
    --cc=virtualization@lists.linux.dev \
    /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: link
Be 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.