> 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? > > -- > Best regards, > Dmitry
I see the command but can't find the corresponding bug. The email is sent to [email protected] address but the HASH does not correspond to any known bug. Please double check the address.
