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@xxxxxxxxxxxxxxxxxxxxxxxxx
>> Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224
>> Reported-by: syzbot+908bd910da5dd79b88de4cf7baf376cc873a922e@xxxxxxxxxxxxxxxxxxxxxxxxx
>> Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e
>> Signed-off-by: Ryosuke Yasuoka <ryasuoka@xxxxxxxxxx>
>> ---
>>  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