The commit is pushed to "branch-rh10-6.12.0-55.52.1.5.x.vz10-ovz" and will 
appear at [email protected]:openvz/vzkernel.git
after rh10-6.12.0-55.52.1.5.25.vz10
------>
commit 4ff28534c7990b106f501025f2de13b559504bed
Author: Denis V. Lunev <[email protected]>
Date:   Fri May 15 14:31:15 2026 +0200

    ms/vhost/vsock: Refuse the connection immediately when guest isn't ready
    
    When the host initiates an AF_VSOCK connect() to a guest that has not
    yet loaded the virtio-vsock transport (i.e. still booting), the caller
    blocks for VSOCK_DEFAULT_CONNECT_TIMEOUT.
    
    A caller that wants to know if the guest is up yet instead of waiting
    could theoretically tune SO_VM_SOCKETS_CONNECT_TIMEOUT, but it's tricky
    to find the right timeout, if not impossible: there's no way to
    distinguish "guest won't reply because it's not up yet" vs "guest is up
    and tried to reply, but was too slow".
    
    Furthermore, this delay is pointless:
    - If the guest doesn't initialize within this timeout, connect()
      returns ETIMEDOUT.
    - If the guest **does** initialize, it'll reply with RST immediately,
      because there won't be a listener on the port yet; connect() returns
      ECONNRESET.
    
    That's also inconsistent with the behavior at other initialization
    stages: if a connection is attempted when the guest driver is already
    loaded, but nothing is listening yet, we return ECONNRESET immediately
    without waiting.
    
    Fix this by checking the RX virtqueue backend in
    vhost_transport_send_pkt() before queuing. If it's NULL, return
    -EHOSTUNREACH immediately.
    
    Callers that used to get ETIMEDOUT will now usually get EHOSTUNREACH.
    
    Signed-off-by: Denis V. Lunev <[email protected]>
    Co-developed-by: Polina Vishneva <[email protected]>
    Signed-off-by: Polina Vishneva <[email protected]>
    
    Reviewed-by: Stefano Garzarella <[email protected]>
    
    That's the upstream reviewed version (that's about to get accepted).
    Link: 
https://lore.kernel.org/lkml/[email protected]/
    
    https://virtuozzo.atlassian.net/browse/VSTOR-128710
    
    Feature: fix ms/vsock
---
 drivers/vhost/vsock.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index edc15f7259262..0a518c3d15965 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -285,6 +285,22 @@ vhost_transport_send_pkt(struct sk_buff *skb)
                return -ENODEV;
        }
 
+       /* Fast-fail if the guest hasn't enabled the RX vq yet. Queuing the 
packet
+        * and making the caller wait is pointless: even if the guest manages 
to init
+        * within the timeout, it'll immediately reply with RST, because 
there's no
+        * listener on the port yet.
+        *
+        * vhost_vq_get_backend() without vq->mutex is acceptable here: locking
+        * the mutex would be too expensive in this hot path, and we already 
have
+        * all the outcomes covered: if the backend becomes NULL right after 
the check,
+        * vhost_transport_do_send_pkt() will check it under the mutex anyway.
+        */
+       if 
(unlikely(!data_race(vhost_vq_get_backend(&vsock->vqs[VSOCK_VQ_RX])))) {
+               rcu_read_unlock();
+               kfree_skb(skb);
+               return -EHOSTUNREACH;
+       }
+
        if (virtio_vsock_skb_reply(skb))
                atomic_inc(&vsock->queued_replies);
 
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel

Reply via email to