[Devel] [PATCH hci-8.0 1/1] drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue worker

[Denis V. Lunev <den@openvz.org>]

From: Ryosuke Yasuoka <ryasuoka@redhat.com>

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@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 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 1c15cbf326b7..4a25347734fd 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 8181b22b9b46..412384e16dae 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,
-- 
2.53.0