[Devel] [PATCH vz10 4/5] fixup! vhost/vsock: re-scan TX virtqueue on device start

[Konstantin Khorenko]

already applied here

The commit is pushed to "branch-rh10-6.12.0-211.16.1.12.x.vz10-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git
after rh10-6.12.0-211.16.1.12.5.vz10
------>
commit 67fdd1befc4da39f114de9a2ad4e725ea442a034
Author: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com>
Date:   Thu Jun 4 18:46:13 2026 +0300

    vhost/vsock: re-scan TX virtqueue on device start
    
    During QEMU CPR live-update (and VHOST_RESET_OWNER in general) the guest
    keeps running while the host drops and later re-attaches vhost backends.
    If the guest adds a buffer to the TX virtqueue (guest->host) and kicks
    while the backend is temporarily NULL (between vhost_vsock_drop_backends()
    and the next vhost_vsock_start()), then the kick is delivered to the
    vhost worker, handle_tx_kick() sees a NULL backend and returns, and the
    kick signal is consumed.  The buffer is then left in the ring.
    
    Then upon device start vhost_vsock_start() only re-kicks the RX send
    worker, never the TX VQ, so the buffer is processed only if the guest
    happens to kick again.  But if the guest itself is now waiting for data
    from the host, it will never kick TX VQ again, and we end up in a
    deadlock.
    
    The deadlock is reproduced during active host->guest socat data transfer
    under multiple consecutive qemu-update's.
    
    To fix this, in vhost_vsock_start(), after kicking the RX send worker, also
    queue the TX vq poll so any buffers the guest enqueued while we were paused
    get scanned.
    
    https://virtuozzo.atlassian.net/browse/VSTOR-131956
    https://virtuozzo.atlassian.net/browse/VSTOR-101116
    Reviewed-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
    Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com>
    Feature: vhost-vsock: VHOST_RESET_OWNER ioctl

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 6/25/26 20:16, Eva Kurchatova wrote:
> From: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com>
> 
> During QEMU CPR live-update (and VHOST_RESET_OWNER in general) the guest
> keeps running while the host drops and later re-attaches vhost backends.
> If the guest adds a buffer to the TX virtqueue (guest->host) and kicks
> while the backend is temporarily NULL (between vhost_vsock_drop_backends()
> and the next vhost_vsock_start()), then the kick is delivered to the
> vhost worker, handle_tx_kick() sees a NULL backend and returns, and the
> kick signal is consumed.  The buffer is then left in the ring.
> 
> Then upon device start vhost_vsock_start() only re-kicks the RX send
> worker, never the TX VQ, so the buffer is processed only if the guest
> happens to kick again.  But if the guest itself is now waiting for data
> from the host, it will never kick TX VQ again, and we end up in a
> deadlock.
> 
> The deadlock is reproduced during active host->guest socat data transfer
> under multiple consecutive qemu-update's.
> 
> To fix this, in vhost_vsock_start(), after kicking the RX send worker, also
> queue the TX vq poll so any buffers the guest enqueued while we were paused
> get scanned.
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-131956
> https://virtuozzo.atlassian.net/browse/VSTOR-101116
> 
> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com>
> 
> Feature: vhost-vsock: VHOST_RESET_OWNER ioctl
> ---
>  drivers/vhost/vsock.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index f652f47956d7..2cee40a1ca04 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -634,6 +634,12 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)
>  	/* See vhost_transport_send_pkt(); never cleared. */
>  	WRITE_ONCE(vsock->started_once, true);
>  
> +	/*
> +	 * Some packets might've also been queued in TX VQ.  Re-scan it here,
> +	 * mirroring the RX send-worker kick above.
> +	 */
> +	vhost_poll_queue(&vsock->vqs[VSOCK_VQ_TX].poll);
> +
>  	mutex_unlock(&vsock->dev.mutex);
>  	return 0;
>