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+d6dd6f86d3aaf7eebe7406e45c1c6e549453f...@syzkaller.appspotmail.com >> Closes: >> https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224 >> Reported-by: >> syzbot+908bd910da5dd79b88de4cf7baf376cc873a9...@syzkaller.appspotmail.com >> Closes: >> https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e >> Signed-off-by: Ryosuke Yasuoka <[email protected]> >> --- >> 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
