From: Konstantin Khorenko <khorenko@virtuozzo.com>
Subject: [Devel] [PATCH RHEL10 COMMIT] ms/drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue worker
Date: Wed, 12 Aug 2026 18:59:58 +0200 [thread overview]
Message-ID: <202608121659.67CGxwqw177336@f0.sw.ru> (raw)
In-Reply-To: <20260812141857.1186094-1-den@openvz.org>
The commit is pushed to "branch-rh10-6.12.0-211.39.1.16.x.vz10-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git
after rh10-6.12.0-211.39.1.16.3.vz10
------>
commit ff8aae3c80cecda20c3a48f3fa00b837c614943c
Author: Ryosuke Yasuoka <ryasuoka@redhat.com>
Date: Wed Aug 12 16:18:57 2026 +0200
ms/drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue worker
A probe-time deadlock can occur between the dequeue worker and
drm_client_register(). During probe, drm_client_register() holds
clientlist_mutex and calls the fbdev hotplug callback, which triggers an
atomic commit that ends up sleeping in virtio_gpu_queue_ctrl_sgs()
waiting for virtqueue space. The dequeue worker that would free that
space calls virtio_gpu_cmd_get_display_info_cb(), which invokes
drm_kms_helper_hotplug_event() -> drm_client_dev_hotplug(), attempting
to acquire the same clientlist_mutex. Since wake_up() is only called
after the resp_cb loop, the probe thread is never woken and both threads
deadlock.
Fix this by removing the hotplug notification from
virtio_gpu_cmd_get_display_info_cb(). The display data (outputs[i].info)
is still updated synchronously in the callback.
For the init path, drm_client_register() already fires an initial
hotplug when the client is registered, which picks up the connector
state updated by display_info_cb.
For the runtime config_changed path, add a wait_event_timeout() in
config_changed_work_func() so that display_info_cb updates the connector
data before the hotplug notification is sent. Also replace
drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event() since
virtio-gpu never calls drm_kms_helper_poll_init() and thus
drm_helper_hpd_irq_event() always returns false without doing anything.
Fixes: 27655b9bb9f0 ("drm/client: Send hotplug event after registering a client")
Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
Suggested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patch.msgid.link/20260713-virtiogpu_syzbot-v2-1-2958fa37d46d at redhat.com
(cherry picked from commit d1b894c5bbb3fee0012bd14356286dc2384e8213)
VHI hit the runtime variant of this deadlock in a compute test run.
An almalinux-10 guest froze mid-boot, roughly once in 20 boots, with
the serial console and the VGA output both stuck a moment after fbcon
came up. The dequeue worker gets past clientlist_mutex there and
blocks one frame further in, on the modeset ww_mutex held by the fbdev
damage worker:
kworker/0:1 Workqueue: events drm_fb_helper_damage_work
drm_fb_helper_damage_work -> drm_fbdev_shmem_helper_fb_dirty
-> drm_atomic_helper_dirtyfb holds the modeset ww_mutexes
-> drm_atomic_commit -> virtio_gpu_primary_plane_update
-> virtio_gpu_queue_ctrl_sgs waits for ctrl-vq descriptors
kworker/0:3 Workqueue: events virtio_gpu_dequeue_ctrl_func
virtio_gpu_dequeue_ctrl_func the only code that frees them
-> drm_client_dev_hotplug -> drm_fb_helper_hotplug_event
-> drm_client_modeset_probe -> drm_modeset_lock_all_ctx
waits for the same ww_mutexes
Both waits are uninterruptible, so the guest never recovers. The
console dies with it: setfont blocks in drm_fb_helper_pan_display
while holding console_lock, and systemd blocks on console_sem in
tty_open, which is where the boot stops.
Cherry-pick applied cleanly, no conflicts.
https://virtuozzo.atlassian.net/browse/VSTOR-141131
Feature: fix ms/drm/virtio
Signed-off-by: Denis V. Lunev <den@openvz.org>
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 5 ++++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 3 ---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 1c15cbf326b78..4a25347734fda 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -48,7 +48,10 @@ static void virtio_gpu_config_changed_work_func(struct work_struct *work)
virtio_gpu_cmd_get_edids(vgdev);
virtio_gpu_cmd_get_display_info(vgdev);
virtio_gpu_notify(vgdev);
- drm_helper_hpd_irq_event(vgdev->ddev);
+ wait_event_timeout(vgdev->resp_wq,
+ !vgdev->display_info_pending,
+ 5 * HZ);
+ drm_kms_helper_hotplug_event(vgdev->ddev);
}
events_clear |= VIRTIO_GPU_EVENT_DISPLAY;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 8181b22b9b46a..412384e16daea 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -839,9 +839,6 @@ static void virtio_gpu_cmd_get_display_info_cb(struct virtio_gpu_device *vgdev,
vgdev->display_info_pending = false;
spin_unlock(&vgdev->display_info_lock);
wake_up(&vgdev->resp_wq);
-
- if (!drm_helper_hpd_irq_event(vgdev->ddev))
- drm_kms_helper_hotplug_event(vgdev->ddev);
}
static void virtio_gpu_cmd_get_capset_info_cb(struct virtio_gpu_device *vgdev,
prev parent reply other threads:[~2026-08-12 16:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 14:18 [Devel] [PATCH hci-8.0 1/1] drm/virtio: " Denis V. Lunev
2026-08-12 16:59 ` Konstantin Khorenko [this message]
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=202608121659.67CGxwqw177336@f0.sw.ru \
--to=khorenko@virtuozzo.com \
/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.