From: Polina Vishneva <polina.vishneva@virtuozzo.com>
To: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org, virtualization@lists.linux.dev,
kvm@vger.kernel.org, "Eugenio Pérez" <eperezma@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Polina Vishneva" <polina.vishneva@virtuozzo.com>,
"Denis V . Lunev" <den@openvz.org>
Subject: [PATCH v2] vhost/vsock: Refuse the connection immediately when guest isn't ready
Date: Wed, 13 May 2026 16:50:04 +0200 [thread overview]
Message-ID: <20260513145842.809404-1-polina.vishneva@virtuozzo.com> (raw)
From: "Denis V. Lunev" <den@openvz.org>
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 <den@openvz.org>
Co-developed-by: Polina Vishneva <polina.vishneva@virtuozzo.com>
Signed-off-by: Polina Vishneva <polina.vishneva@virtuozzo.com>
---
v2:
- ECONNREFUSED -> EHOSTUNREACH.
- Use vhost_transport_do_send_pkt() instead of raw .private_data access.
- Removed READ_ONCE().
- Wrapped the condition with unlikely().
- Updated the comment and the commit message.
v1: https://lore.kernel.org/netdev/20260511145610.413210-1-polina.vishneva@virtuozzo.com
drivers/vhost/vsock.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 1d8ec6bed53e..9aaab6bb8061 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -302,6 +302,22 @@ vhost_transport_send_pkt(struct sk_buff *skb, struct net *net)
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);
base-commit: 8ab992f815d6736b5c7a6f5fd7bfe7bc106bb3dc
--
2.53.0
reply other threads:[~2026-05-13 14:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260513145842.809404-1-polina.vishneva@virtuozzo.com \
--to=polina.vishneva@virtuozzo.com \
--cc=den@openvz.org \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox