[PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[Ryosuke Yasuoka]

virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
wait_event() without timeout when waiting for virtqueue space. If the
host device stops processing commands, these waits block indefinitely.
Since callers may hold DRM locks, this can make the entire system
unresponsive.

Replace wait_event() with wait_event_timeout() using a 5-second timeout,
consistent with the existing timeout pattern in the driver. On timeout,
clean up and return -ENODEV, following the same error path as
drm_dev_enter() failure.

Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 67865810a2e7..05e816a0ae0b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -396,7 +396,16 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
 	if (vq->num_free < elemcnt) {
 		spin_unlock(&vgdev->ctrlq.qlock);
 		virtio_gpu_notify(vgdev);
-		wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= elemcnt);
+		if (!wait_event_timeout(vgdev->ctrlq.ack_queue,
+					vq->num_free >= elemcnt,
+					5 * HZ)) {
+			/* The device did not respond */
+			if (fence && vbuf->objs)
+				virtio_gpu_array_unlock_resv(vbuf->objs);
+			free_vbuf(vgdev, vbuf);
+			drm_dev_exit(idx);
+			return -ENODEV;
+		}
 		goto again;
 	}
 
@@ -566,7 +575,14 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
 	ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
 	if (ret == -ENOSPC) {
 		spin_unlock(&vgdev->cursorq.qlock);
-		wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
+		if (!wait_event_timeout(vgdev->cursorq.ack_queue,
+					vq->num_free >= outcnt,
+					5 * HZ)) {
+			/* The device did not respond */
+			free_vbuf(vgdev, vbuf);
+			drm_dev_exit(idx);
+			return;
+		}
 		spin_lock(&vgdev->cursorq.qlock);
 		goto retry;
 	} else {

---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260512-virtio-gpu_wait_event-e0cdf8675b7c

Best regards,
-- 
Ryosuke Yasuoka <ryasuoka@redhat.com>

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[syzbot]

> virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
> wait_event() without timeout when waiting for virtqueue space. If the
> host device stops processing commands, these waits block indefinitely.
> Since callers may hold DRM locks, this can make the entire system
> unresponsive.
>
> Replace wait_event() with wait_event_timeout() using a 5-second timeout,
> consistent with the existing timeout pattern in the driver. On timeout,
> clean up and return -ENODEV, following the same error path as
> drm_dev_enter() failure.
>
> Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
> ---
>  drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 67865810a2e7..05e816a0ae0b 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -396,7 +396,16 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
>  	if (vq->num_free < elemcnt) {
>  		spin_unlock(&vgdev->ctrlq.qlock);
>  		virtio_gpu_notify(vgdev);
> -		wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= elemcnt);
> +		if (!wait_event_timeout(vgdev->ctrlq.ack_queue,
> +					vq->num_free >= elemcnt,
> +					5 * HZ)) {
> +			/* The device did not respond */
> +			if (fence && vbuf->objs)
> +				virtio_gpu_array_unlock_resv(vbuf->objs);
> +			free_vbuf(vgdev, vbuf);
> +			drm_dev_exit(idx);
> +			return -ENODEV;
> +		}
>  		goto again;
>  	}
>  
> @@ -566,7 +575,14 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
>  	ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
>  	if (ret == -ENOSPC) {
>  		spin_unlock(&vgdev->cursorq.qlock);
> -		wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
> +		if (!wait_event_timeout(vgdev->cursorq.ack_queue,
> +					vq->num_free >= outcnt,
> +					5 * HZ)) {
> +			/* The device did not respond */
> +			free_vbuf(vgdev, vbuf);
> +			drm_dev_exit(idx);
> +			return;
> +		}
>  		spin_lock(&vgdev->cursorq.qlock);
>  		goto retry;
>  	} else {
>
> ---
> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
> change-id: 20260512-virtio-gpu_wait_event-e0cdf8675b7c
>
> Best regards,
> -- 
> Ryosuke Yasuoka <ryasuoka@redhat.com>
>

I see the command but can't find the corresponding bug.
The email is sent to  syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[syzbot]

> virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
> wait_event() without timeout when waiting for virtqueue space. If the
> host device stops processing commands, these waits block indefinitely.
> Since callers may hold DRM locks, this can make the entire system
> unresponsive.
>
> Replace wait_event() with wait_event_timeout() using a 5-second timeout,
> consistent with the existing timeout pattern in the driver. On timeout,
> clean up and return -ENODEV, following the same error path as
> drm_dev_enter() failure.
>
> Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
> ---
>  drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 67865810a2e7..05e816a0ae0b 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -396,7 +396,16 @@ static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
>  	if (vq->num_free < elemcnt) {
>  		spin_unlock(&vgdev->ctrlq.qlock);
>  		virtio_gpu_notify(vgdev);
> -		wait_event(vgdev->ctrlq.ack_queue, vq->num_free >= elemcnt);
> +		if (!wait_event_timeout(vgdev->ctrlq.ack_queue,
> +					vq->num_free >= elemcnt,
> +					5 * HZ)) {
> +			/* The device did not respond */
> +			if (fence && vbuf->objs)
> +				virtio_gpu_array_unlock_resv(vbuf->objs);
> +			free_vbuf(vgdev, vbuf);
> +			drm_dev_exit(idx);
> +			return -ENODEV;
> +		}
>  		goto again;
>  	}
>  
> @@ -566,7 +575,14 @@ static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
>  	ret = virtqueue_add_sgs(vq, sgs, outcnt, 0, vbuf, GFP_ATOMIC);
>  	if (ret == -ENOSPC) {
>  		spin_unlock(&vgdev->cursorq.qlock);
> -		wait_event(vgdev->cursorq.ack_queue, vq->num_free >= outcnt);
> +		if (!wait_event_timeout(vgdev->cursorq.ack_queue,
> +					vq->num_free >= outcnt,
> +					5 * HZ)) {
> +			/* The device did not respond */
> +			free_vbuf(vgdev, vbuf);
> +			drm_dev_exit(idx);
> +			return;
> +		}
>  		spin_lock(&vgdev->cursorq.qlock);
>  		goto retry;
>  	} else {
>
> ---
> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
> change-id: 20260512-virtio-gpu_wait_event-e0cdf8675b7c
>
> Best regards,
> -- 
> Ryosuke Yasuoka <ryasuoka@redhat.com>
>

I see the command but can't find the corresponding bug.
The email is sent to  syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[Dmitry Osipenko]

Hi,

On 5/12/26 11:59, Ryosuke Yasuoka wrote:
> virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
> wait_event() without timeout when waiting for virtqueue space. If the
> host device stops processing commands, these waits block indefinitely.
> Since callers may hold DRM locks, this can make the entire system
> unresponsive.
> 
> Replace wait_event() with wait_event_timeout() using a 5-second timeout,
> consistent with the existing timeout pattern in the driver. On timeout,
> clean up and return -ENODEV, following the same error path as
> drm_dev_enter() failure.
> 
> Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
> ---
>  drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)

If host stops processing commands, this is a problem on host side. Isn't it?

-- 
Best regards,
Dmitry

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[syzbot]

> Hi,
>
> On 5/12/26 11:59, Ryosuke Yasuoka wrote:
>> virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
>> wait_event() without timeout when waiting for virtqueue space. If the
>> host device stops processing commands, these waits block indefinitely.
>> Since callers may hold DRM locks, this can make the entire system
>> unresponsive.
>> 
>> Replace wait_event() with wait_event_timeout() using a 5-second timeout,
>> consistent with the existing timeout pattern in the driver. On timeout,
>> clean up and return -ENODEV, following the same error path as
>> drm_dev_enter() failure.
>> 
>> Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
>> ---
>>  drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
>>  1 file changed, 18 insertions(+), 2 deletions(-)
>
> If host stops processing commands, this is a problem on host side. Isn't it?
>
> -- 
> Best regards,
> Dmitry

I see the command but can't find the corresponding bug.
The email is sent to  syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[syzbot]

> Hi,
>
> On 5/12/26 11:59, Ryosuke Yasuoka wrote:
>> virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
>> wait_event() without timeout when waiting for virtqueue space. If the
>> host device stops processing commands, these waits block indefinitely.
>> Since callers may hold DRM locks, this can make the entire system
>> unresponsive.
>> 
>> Replace wait_event() with wait_event_timeout() using a 5-second timeout,
>> consistent with the existing timeout pattern in the driver. On timeout,
>> clean up and return -ENODEV, following the same error path as
>> drm_dev_enter() failure.
>> 
>> Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
>> ---
>>  drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
>>  1 file changed, 18 insertions(+), 2 deletions(-)
>
> If host stops processing commands, this is a problem on host side. Isn't it?
>
> -- 
> Best regards,
> Dmitry

I see the command but can't find the corresponding bug.
The email is sent to  syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[Dmitry Osipenko]

On 5/14/26 00:40, Dmitry Osipenko wrote:
> Hi,
> 
> On 5/12/26 11:59, Ryosuke Yasuoka wrote:
>> virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
>> wait_event() without timeout when waiting for virtqueue space. If the
>> host device stops processing commands, these waits block indefinitely.
>> Since callers may hold DRM locks, this can make the entire system
>> unresponsive.
>>
>> Replace wait_event() with wait_event_timeout() using a 5-second timeout,
>> consistent with the existing timeout pattern in the driver. On timeout,
>> clean up and return -ENODEV, following the same error path as
>> drm_dev_enter() failure.
>>
>> Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
>> ---
>>  drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
>>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> If host stops processing commands, this is a problem on host side. Isn't it?

It may be acceptable to have wait_event_timeout() in a loop, printing
warnings about unresponsive host.

Don't think we can assume that 5 seconds is enough to say that host is
busted, unless spec says so.

There could be a driver module parameter, specifying the timeoout. This
will be acceptable as user takes responsibility for the special timeout
behaviour.

-- 
Best regards,
Dmitry

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[Ryosuke Yasuoka]

Hi Dmitry,

Thank you for your review.

On 14/05/2026 00:54, Dmitry Osipenko wrote:
> On 5/14/26 00:40, Dmitry Osipenko wrote:
>> Hi,
>> 
>> On 5/12/26 11:59, Ryosuke Yasuoka wrote:
>>> virtio_gpu_queue_ctrl_sgs() and virtio_gpu_queue_cursor() use
>>> wait_event() without timeout when waiting for virtqueue space. If the
>>> host device stops processing commands, these waits block indefinitely.
>>> Since callers may hold DRM locks, this can make the entire system
>>> unresponsive.
>>>
>>> Replace wait_event() with wait_event_timeout() using a 5-second timeout,
>>> consistent with the existing timeout pattern in the driver. On timeout,
>>> clean up and return -ENODEV, following the same error path as
>>> drm_dev_enter() failure.
>>>
>>> Reported-by: syzbot+d6dd6f86d3aaf7eebe7406e45c1c6e549453f224@syzkaller.appspotmail.com
>>> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>>> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@syzkaller.appspotmail.com
>>> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>>> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
>>> ---
>>>  drivers/gpu/drm/virtio/virtgpu_vq.c | 20 ++++++++++++++++++--
>>>  1 file changed, 18 insertions(+), 2 deletions(-)
>> 
>> If host stops processing commands, this is a problem on host side. Isn't it?

Yes, it is. But the guest has no way to recover from this situation on
its own. The wait_event{,_timeout}() is inside the device critical
section between drm_dev_enter/exit(). Removing the device via sysfs and
graceful shutdown call drm_dev_unplug(), which is blocked until the
critical section completes, so they cannot proceed either. Also, IIUC
the virtio-gpu device cannot be hot-unplugged from the host side. The
only option left is a forced reboot.

> It may be acceptable to have wait_event_timeout() in a loop, printing
> warnings about unresponsive host.

I considered this approach, but it does not solve the recovery problem
described above. The guest would still be stuck in the loop with no way
to remove the device or shut down gracefully.

> Don't think we can assume that 5 seconds is enough to say that host is
> busted, unless spec says so.
> 
> There could be a driver module parameter, specifying the timeoout. This
> will be acceptable as user takes responsibility for the special timeout
> behaviour.

Agreed. In v2, the default behavior is preserved (wait_event, wait
indefinitely). A new 'timeout' module parameter (in seconds) lets the
user specify when to give up. When set to a non-zero value, the driver
returns -ENODEV after the specified duration with a warning message.

Also, I'm considering proposing a host response timeout in the
virtio-gpu specificaiton. If a spec-defined timeout is accepted in the
future, the driver could use it as the default instead of relying on the
module parameter.

Best regards,
Ryosuke

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[Dmitry Osipenko]

On 5/18/26 09:45, Ryosuke Yasuoka wrote:
>> It may be acceptable to have wait_event_timeout() in a loop, printing
>> warnings about unresponsive host.
> I considered this approach, but it does not solve the recovery problem
> described above. The guest would still be stuck in the loop with no way
> to remove the device or shut down gracefully.

Could `system_state != SYSTEM_RUNNING` be checked in the wait loop? This
may allow to handle system shutdown, aborting the timed out wait in the
special case.

Userspace may also get stuck in a zombie state. For that, code should
use wait_event_interruptible(). But driver has code unprepared to be
interrupted, it all needs to be reworked first [1].

Similarly, for unbind there could a driver flag that the wait loop will
check and handle specially.

WDYT?

[1]
https://lore.kernel.org/dri-devel/20260515084030.21986-1-kartikey406@gmail.com/

-- 
Best regards,
Dmitry

Re: [PATCH] drm/virtio: add timeout to virtqueue wait to avoid hung task

[Ryosuke Yasuoka]

Thank you for the suggestions.

On 19/05/2026 09:11, Dmitry Osipenko wrote:
> On 5/18/26 09:45, Ryosuke Yasuoka wrote:
>>> It may be acceptable to have wait_event_timeout() in a loop, printing
>>> warnings about unresponsive host.
>> I considered this approach, but it does not solve the recovery problem
>> described above. The guest would still be stuck in the loop with no way
>> to remove the device or shut down gracefully.
> 
> Could `system_state != SYSTEM_RUNNING` be checked in the wait loop? This
> may allow to handle system shutdown, aborting the timed out wait in the
> special case.

Instead of checking system_state directly, I'm planning to add a driver
flag (e.g. vqs_released) to struct virtio_gpu_device. The shutdown path
(virtio_gpu_shutdown) will set this flag and wake up the wait queues
before calling drm_dev_unplug(). The wait loop checks the flag and
aborts if set. This may cover both the shutdown and the unbind cases
with a sinble check, so I believe a separate system_state check is not
needed. If my plan turns out to have issues, I will use system_state
check.

> Userspace may also get stuck in a zombie state. For that, code should
> use wait_event_interruptible(). But driver has code unprepared to be
> interrupted, it all needs to be reworked first [1].

Agreed. I will leave wait_event_interruptible() for follow-up once the
interruptible is prepared. For now, userspace stuck in D state remains a
pre-exsiting limitation.

> Similarly, for unbind there could a driver flag that the wait loop will
> check and handle specially.

Yes, the driver flag described above will handle this as well.

Best regards,
Ryosuke

> WDYT?
> 
> [1]
> https://lore.kernel.org/dri-devel/20260515084030.21986-1-kartikey406@gmail.com/