From: Stefano Garzarella <sgarzare@redhat.com>
To: Bobby Eshleman <bobbyeshleman@meta.com>
Cc: "David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowangio@gmail.com>,
"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Donald Hunter" <donald.hunter@gmail.com>,
"Eric Dumazet" <edumazet@kernel.org>,
virtualization@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
sargun@sargun.me, jlinbox@meta.com,
"Bobby Eshleman" <bobbyeshleman@gmail.com>
Subject: Re: [PATCH net-next v4 5/7] vsock/virtio: support guest device network namespace
Date: Wed, 21 Oct 2026 19:03:42 +0200 [thread overview]
Message-ID: <atjvzn-zPYJjLAhy@sgarzare-redhat> (raw)
In-Reply-To: <20261020-vsock-guest-ns-v4-5-047527cfccfc@meta.com>
On Tue, Oct 20, 2026 at 06:15:08PM -0700, Bobby Eshleman wrote:
>virtio-vsock did not have namespace support (the device was always
>accessible to any global namespace).
>
>Make the virtio-vsock device assignable to a namespace and initialize it
>to init_net. Because virtio-vsock and init_net are both hardcoded to
>global mode, nothing changes until the assign command is issued.
>
>An assign can land while virtio_transport_rx_work() is draining a
>batch, so the assigned namespace is re-read per packet rather than once
>per batch. Matching the rest of the batch against the namespace the
>device has left would reset connections that belong to the new one.
>
>When a device is assigned to a namespace, every already established
>vsock socket that is no longer able to reach the device is forcibly
>closed. For that reason, adding new sockets to the connected table must
>be performed atomically with regards to namespace assignment. This
>ensures that when the socket is added to the connected table that it
>actually passes the new reachability conditions set by ns assignment. If
>it wins the race to the table and does NOT pass the reachability tests,
>then it will be reset. This is the purpose of the new helper
>'vsock_maybe_set_connected()'.
>
>Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
>---
>Changes in v4:
>- Drop packets in virtio_transport_send_pkt() from a netns that cannot
> reach the device, e.g. shutdown() or credit updates on a swept socket
> (Sashiko)
>
>Changes in v3:
>- Re-read the assigned netns per packet in virtio_transport_rx_work()
> rather than once per batch, so a mid-batch assign cannot reset the new
> namespace's connections (Sashiko)
>- Drop the NULL netns reset in virtio_transport_rx_work(), the assigned
> netns is now pinned
>- Drop the .reset op and the virtio_transport_reset{,_no_sock}() exports,
> the sweep no longer sends a RST (Sashiko)
>
>Changes in v2:
>- Export virtio_transport_reset(), wire it to the new .reset op (Stefano)
>- netns_assign_allow is now a bool (Stefano)
>- Pass NULL, not &init_net, in virtio_transport_rx_work(), and
> comment why (Stefano)
>- Drop the if (net) guard around put_net() (Stefano)
>- Drop the comments at the vsock_maybe_set_connected() call sites,
> the commit msg seems sufficient
>---
> net/vmw_vsock/virtio_transport.c | 32 +++++++++++++++++++++++++++-----
> net/vmw_vsock/virtio_transport_common.c | 18 +++++++++++++-----
> 2 files changed, 40 insertions(+), 10 deletions(-)
>
>diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
>index eced6929405d..06df82b130cf 100644
>--- a/net/vmw_vsock/virtio_transport.c
>+++ b/net/vmw_vsock/virtio_transport.c
>@@ -256,6 +256,15 @@ virtio_transport_send_pkt(struct sk_buff *skb, struct net *net)
> goto out_rcu;
> }
>
>+ /* A socket reset by an assign can still send credit updates from
>+ * recvmsg() and setsockopt(SO_RCVLOWAT).
>+ */
>+ if (!vsock_g2h_net_reachable(net)) {
>+ kfree_skb(skb);
>+ len = -ENETUNREACH;
>+ goto out_rcu;
>+ }
>+
> /* If send_pkt_queue is empty, we can safely bypass this queue
> * because packet order is maintained and (try) to put the packet
> * on the virtqueue using virtio_transport_send_skb_fast_path.
>@@ -542,7 +551,7 @@ static bool virtio_transport_msgzerocopy_allow(void)
>
> bool virtio_transport_stream_allow(struct vsock_sock *vsk, u32 cid, u32 port)
> {
>- return vsock_net_mode_global(vsk);
>+ return vsock_g2h_net_reachable(sock_net(sk_vsock(vsk)));
> }
>
> static bool virtio_transport_seqpacket_allow(struct vsock_sock *vsk,
>@@ -587,6 +596,7 @@ static struct virtio_transport virtio_transport = {
> .seqpacket_has_data = virtio_transport_seqpacket_has_data,
>
> .msgzerocopy_allow = virtio_transport_msgzerocopy_allow,
>+ .netns_assign_allow = true,
>
> .notify_poll_in = virtio_transport_notify_poll_in,
> .notify_poll_out = virtio_transport_notify_poll_out,
>@@ -616,7 +626,7 @@ virtio_transport_seqpacket_allow(struct vsock_sock *vsk, u32 remote_cid)
> struct virtio_vsock *vsock;
> bool seqpacket_allow;
>
>- if (!vsock_net_mode_global(vsk))
>+ if (!vsock_g2h_net_reachable(sock_net(sk_vsock(vsk))))
> return false;
>
> seqpacket_allow = false;
>@@ -633,7 +643,12 @@ static void virtio_transport_rx_work(struct work_struct *work)
> {
> struct virtio_vsock *vsock =
> container_of(work, struct virtio_vsock, rx_work);
>+ struct virtio_transport *t = &virtio_transport;
>+ netns_tracker ns_tracker;
> struct virtqueue *vq;
>+ struct net *net;
>+
>+ net = vsock_g2h_net_get(&ns_tracker);
>
> mutex_lock(&vsock->rx_lock);
>
>@@ -682,10 +697,15 @@ static void virtio_transport_rx_work(struct work_struct *work)
>
> virtio_transport_deliver_tap_pkt(skb);
>
>- /* Force virtio-transport into global mode since it
>- * does not yet support local-mode namespacing.
>+ /* Only grab a reference if the net changes underneath
>+ * us.
> */
>- virtio_transport_recv_pkt(&virtio_transport, skb, NULL);
>+ if (unlikely(!vsock_g2h_net_eq(net))) {
>+ put_net_track(net, &ns_tracker);
>+ net = vsock_g2h_net_get(&ns_tracker);
>+ }
>+
>+ virtio_transport_recv_pkt(t, skb, net);
> }
> } while (!virtqueue_enable_cb(vq));
>
>@@ -694,6 +714,8 @@ static void virtio_transport_rx_work(struct work_struct *work)
> virtio_vsock_rx_fill(vsock);
> out_nofill:
> mutex_unlock(&vsock->rx_lock);
>+
>+ put_net_track(net, &ns_tracker);
> }
>
> static int virtio_vsock_vqs_init(struct virtio_vsock *vsock)
>diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>index 1e762a480df4..0c864db2bc65 100644
>--- a/net/vmw_vsock/virtio_transport_common.c
>+++ b/net/vmw_vsock/virtio_transport_common.c
>@@ -1478,9 +1478,13 @@ virtio_transport_recv_connecting(struct sock *sk,
>
> switch (le16_to_cpu(hdr->op)) {
> case VIRTIO_VSOCK_OP_RESPONSE:
>- sk->sk_state = TCP_ESTABLISHED;
>+ if (!vsock_maybe_set_connected(vsk)) {
>+ skerr = ECONNRESET;
>+ err = -ENETUNREACH;
>+ goto destroy;
>+ }
>+
> sk->sk_socket->state = SS_CONNECTED;
>- vsock_insert_connected(vsk);
> sk->sk_state_change(sk);
> break;
> case VIRTIO_VSOCK_OP_INVALID:
>@@ -1736,8 +1740,6 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
>
> lock_sock_nested(child, SINGLE_DEPTH_NESTING);
>
>- child->sk_state = TCP_ESTABLISHED;
>-
> vchild = vsock_sk(child);
> vsock_addr_init(&vchild->local_addr, le64_to_cpu(hdr->dst_cid),
> le32_to_cpu(hdr->dst_port));
>@@ -1758,7 +1760,13 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
> if (virtio_transport_space_update(child, skb))
> child->sk_write_space(child);
>
>- vsock_insert_connected(vchild);
>+ if (!vsock_maybe_set_connected(vchild)) {
>+ release_sock(child);
>+ virtio_transport_reset_no_sock(t, skb, sock_net(sk));
We might be facing the same issue here that we were discussing a few
days ago in another patch.
I mean, is it correct to send the reset to `sock_net(sk)`?
Or should we use the one of the sender?
Thanks,
Stefano
>+ sock_put(child);
>+ return -ENETUNREACH;
>+ }
>+
> vsock_enqueue_accept(sk, child);
> virtio_transport_send_response(vchild, skb);
>
>
>--
>2.53.0-Meta
>
next prev parent reply other threads:[~2026-10-21 17:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 1:15 [PATCH net-next v4 0/7] vsock: assign the guest vsock device to a network namespace Bobby Eshleman
2026-10-21 1:15 ` [PATCH net-next v4 1/7] vsock: constify the transport in vsock_for_each_connected_socket() Bobby Eshleman
2026-10-21 1:15 ` [PATCH net-next v4 2/7] vsock: rename the vsock pernet operations Bobby Eshleman
2026-10-21 10:11 ` Stefano Garzarella
2026-10-21 1:15 ` [PATCH net-next v4 3/7] vsock: pass the netns to ->has_remote_cid() Bobby Eshleman
2026-10-21 10:14 ` Stefano Garzarella
2026-10-21 1:15 ` [PATCH net-next v4 4/7] vsock: add a netlink command to assign the g2h device to a netns Bobby Eshleman
2026-10-21 16:55 ` Stefano Garzarella
2026-10-22 0:50 ` Bobby Eshleman
2026-10-22 10:47 ` Stefano Garzarella
2026-10-21 1:15 ` [PATCH net-next v4 5/7] vsock/virtio: support guest device network namespace Bobby Eshleman
2026-10-21 17:03 ` Stefano Garzarella [this message]
2026-10-21 1:15 ` [PATCH net-next v4 6/7] selftests/vsock: test the guest vsock " Bobby Eshleman
2026-10-21 1:15 ` [PATCH net-next v4 7/7] selftests/vsock: test the netns assign privilege checks Bobby Eshleman
2026-10-21 1:35 ` [PATCH net-next v4 0/7] vsock: assign the guest vsock device to a network namespace Jakub Kicinski
2026-10-21 9:48 ` Stefano Garzarella
2026-10-21 22:46 ` Bobby Eshleman
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=atjvzn-zPYJjLAhy@sgarzare-redhat \
--to=sgarzare@redhat.com \
--cc=bobbyeshleman@gmail.com \
--cc=bobbyeshleman@meta.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@kernel.org \
--cc=eperezma@redhat.com \
--cc=horms@kernel.org \
--cc=jasowangio@gmail.com \
--cc=jlinbox@meta.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=sargun@sargun.me \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/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