From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/virtio: abort virtqueue wait on device removal to avoid hung task Date: Mon, 25 May 2026 21:05:48 +1000 Message-ID: In-Reply-To: <20260521-virtio-gpu_wait_event-v2-1-5796b3a71d03@redhat.com> References: <20260521-virtio-gpu_wait_event-v2-1-5796b3a71d03@redhat.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: drm/virtio: abort virtqueue wait on device removal to avoid hung t= ask Author: Ryosuke Yasuoka Patches: 9 Reviewed: 2026-05-25T21:05:48.593126 --- This is a single-patch fix for a real syzbot-reported hung task bug in the = virtio-gpu driver. The core problem is well understood: `wait_event()` call= s in `virtio_gpu_queue_ctrl_sgs()` and `virtio_gpu_queue_cursor()` block in= definitely inside `drm_dev_enter()`/`drm_dev_exit()` SRCU critical sections= . Since `drm_dev_unplug()` calls `synchronize_srcu()` which waits for those= critical sections to complete, device removal and shutdown deadlock. The v2 approach =E2=80=94 a driver-level `vqs_released` flag set before `dr= m_dev_unplug()` =E2=80=94 is the right idea and is a clear improvement over= v1's arbitrary timeout. The abort paths correctly mirror the existing `drm= _dev_enter()` failure cleanup. However, I have a few concerns about atomici= ty/ordering, and a potential race window that should be addressed. --- Generated by Claude Code Patch Reviewer