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: Thu, 04 Jun 2026 14:31:07 +1000 Message-ID: In-Reply-To: <20260601-virtio-gpu_wait_event-v3-1-89530517a98a@redhat.com> References: <20260601-virtio-gpu_wait_event-v3-1-89530517a98a@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: 2 Reviewed: 2026-06-04T14:31:07.760561 --- This is a single-patch fix for a real hang scenario in the virtio-gpu drive= r. The problem is well-identified: `wait_event()` calls in `virtio_gpu_queu= e_ctrl_sgs()` and `virtio_gpu_queue_cursor()` can block indefinitely if the= host stops processing commands, and since they're inside `drm_dev_enter()`= /`drm_dev_exit()` critical sections, `drm_dev_unplug()` (which calls `synch= ronize_srcu()`) will also hang, blocking device removal and system shutdown. The approach =E2=80=94 adding a `vqs_released` flag checked in the wait con= dition, set before `drm_dev_unplug()` =E2=80=94 is a reasonable and straigh= tforward solution. The cleanup paths mirror the existing `drm_dev_enter()` = failure paths, which is correct. **Overall: The patch is a solid fix for a real problem. There are a few con= cerns worth raising, mostly around memory ordering and minor style, but not= hing blocking.** --- Generated by Claude Code Patch Reviewer