On Fri, 2025-12-05 at 18:06 +0000, Lorenz Bauer wrote: > Hi, > > I've been chasing a bug when using virtio console to exchange data > between guest and host. It manifests in a process inside the guest > getting stuck while writing to the serial port: > > [<0>] wait_port_writable+0x139/0x2d0 > [<0>] port_fops_write+0x88/0x130 > [<0>] vfs_write+0xf3/0x450 > [<0>] ksys_write+0x6d/0xe0 > [<0>] do_syscall_64+0x9e/0x1a0 > [<0>] entry_SYSCALL_64_after_hwframe+0x77/0x7 > > I managed to track this down to a race in virtio_console.c. The > driver > doesn't properly account for a port that receives blocking writes and > is polled at the same time. I suspect that a similar problem exists > in > port_fops_read(). > > Here is how it goes. We need two threads inside the guest, A and B. > > - Thread A writes to the serial port until the virtqueue fills up. > - Thread A invokes port_fops_write() which calls > wait_port_writable(). > There are no used buffers to reclaim and the thread is suspended, > waiting on port->waitqueue. > - The host side of the device makes some progress, marks some buffers > as consumed / used and sends an interrupt to the guest. > - Before the guest can service the interrupt, thread B executes > port_fops_poll(). This calls into > reclaim_consumed_buffers() via will_write_block(), which removes > all > used buffers. > - The interrupt gets serviced, calling into vring_interrupt(). Here > the check for more_used() returns false because the poll just went > through all the work. The handler returns without waking > port->waitqueue. > - port_fops_write() never returns.
Both port_fops_write() and port_fops_poll() call will_write_block() for checking the block condition -- which is whether port->outvq_full is set. Even if buffers were consumed via poll, outvq_full should just return false, right? Hm, does adding wake_up(port->waitqueue) in case 'ret' is false in will_write_block() help? > I'm not exactly sure how to best fix this. Maybe it's enough to only > check outvq_full in poll? It'd also be nice to fix this on the read > side as well. > > I only have a reproducer which requires a Go toolchain unfortunately: > https://github.com/lmb/vimto/issues/29 > > Best > Lorenz Amit
