Claude review: drm/virtio: add timeout to virtqueue wait to avoid hung task

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/virtio: add timeout to virtqueue wait to avoid hung task
Author: Ryosuke Yasuoka <ryasuoka@redhat.com>
Patches: 7
Reviewed: 2026-05-16T13:58:17.315172

---

This is a single patch addressing a real syzbot-reported hung task problem where `wait_event()` can block indefinitely in `virtio_gpu_queue_ctrl_sgs()` and `virtio_gpu_queue_cursor()` when the host stops processing commands. The approach — replacing `wait_event()` with `wait_event_timeout()` — is a reasonable direction, but the patch has several issues that need to be addressed before it's mergable.

**Key concerns:**

1. **The 5-second timeout is arbitrary and can trigger under legitimate load.** A busy virtio-gpu host might legitimately take more than 5 seconds to drain the queue under heavy load. This would cause spurious `-ENODEV` errors and dropped cursor updates in normal operation. The commit message says "consistent with the existing timeout pattern in the driver" but doesn't cite which existing timeout it refers to. A more robust approach might be to integrate with the device-level health checking (e.g., only bail out if the device has actually been unplugged/reset, or use a much longer timeout).

2. **The `goto again` placement after timeout is correct but subtle.** If `wait_event_timeout` returns non-zero (success), execution falls through to `goto again`, which re-acquires the lock and re-checks the condition. This is correct behavior — matching the original `wait_event` + `goto again` flow — but the diff placement makes it easy to misread.

3. **No logging on timeout.** When the timeout fires in `virtio_gpu_queue_ctrl_sgs`, the driver silently returns `-ENODEV`. There should be at least a `drm_err()` or `drm_dbg()` message so the failure is diagnosable — especially since this path could trigger spuriously.

---

---
Generated by Claude Code Patch Reviewer