All Virtuozzo development lists (kernel + QEMU)
 help / color / mirror / Atom feed
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,

      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.