From: Bobby Eshleman <bobbyeshleman@gmail.com>
To: Jia Jia <physicalmtea@gmail.com>
Cc: stefanha@redhat.com, sgarzare@redhat.com, netdev@vger.kernel.org,
virtualization@lists.linux.dev, kvm@vger.kernel.org,
mst@redhat.com, jasowangio@gmail.com, eperezma@redhat.com,
xuanzhuo@linux.alibaba.com, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: [PATCH net-next v2 1/5] vsock/virtio: split socket lookup from locked RX processing
Date: Tue, 13 Oct 2026 10:16:44 -0700 [thread overview]
Message-ID: <as5nfI0qfqD64dc1@devvm29614.prn0.facebook.com> (raw)
In-Reply-To: <CAJwVaMJL4FFYLq523VY014oa4u7RWD0WUY0+seP1xh3GY5peiQ@mail.gmail.com>
On Tue, Oct 13, 2026 at 11:26:38AM +0800, Jia Jia wrote:
> >
> > On Sat, Oct 10, 2026 at 10:22:43PM +0800, Jia Jia wrote:
> > > Split virtio_transport_recv_pkt() so socket lookup is separate from the
> > > receive state machine that runs under the socket lock.
> > >
> > > Keep virtio_transport_recv_pkt() on its existing per-packet locking path.
> > > Pass the source and destination addresses used for lookup to the locked
> > > receive path so they are decoded only once.
> > >
> > > Pass the network namespace and decoded address tuple through a packet
> > > context to the locked receive path.
> > >
> > > Preserve source validation and failure handling. Keep the lookup reference
> > > separate from the skb owner reference so the locked receive path can manage
> > > the two lifetimes independently.
> > >
> > > Signed-off-by: Jia Jia <physicalmtea@gmail.com>
> > > ---
> > > net/vmw_vsock/virtio_transport_common.c | 139 ++++++++++++++++--------
> > > 1 file changed, 96 insertions(+), 43 deletions(-)
> > >
> >
> > [...]
> >
> > > +/*
> > > + * The caller holds sk's socket lock and must free skb if this returns true.
> > > + */
> > > +static bool
> > > +virtio_transport_recv_pkt_locked(struct virtio_transport *t,
> > > + struct sk_buff *skb, struct sock *sk,
> > > + const struct virtio_transport_rx_pkt_ctx *ctx)
> > > +{
> > > + const struct sockaddr_vm *src = ctx->src;
> > > + const struct sockaddr_vm *dst = ctx->dst;
> > > + struct vsock_sock *vsk = vsock_sk(sk);
> > > + struct net *net = ctx->net;
> > > + bool space_available;
> > >
> > > - /* Check if sk has been closed or assigned to another transport before
> > > - * lock_sock (note: listener sockets are not assigned to any transport)
> > > + /* Check after acquiring the socket lock. Listener sockets accept packets
> > > + * from any source and are not assigned to a transport.
> > > */
> > > if (sock_flag(sk, SOCK_DONE) ||
> > > (sk->sk_state != TCP_LISTEN &&
> > > - !vsock_check_source(vsk, &t->transport, &src))) {
> > > + !vsock_check_source(vsk, &t->transport, src))) {
> > > (void)virtio_transport_reset_no_sock(t, skb, net);
> > > - release_sock(sk);
> > > - sock_put(sk);
> > > - goto free_pkt;
> > > + return true;
> > > }
> > >
> > > space_available = virtio_transport_space_update(sk, skb);
> > >
> > > /* Update CID in case it has changed after a transport reset event */
> > > if (vsk->local_addr.svm_cid != VMADDR_CID_ANY)
> > > - vsk->local_addr.svm_cid = dst.svm_cid;
> > > + vsk->local_addr.svm_cid = dst->svm_cid;
> > >
> > > if (space_available)
> > > sk->sk_write_space(sk);
> > > @@ -1875,12 +1891,49 @@ void virtio_transport_recv_pkt(struct virtio_transport *t,
> > > break;
> > > }
> > >
> > > + return false;
> > > +}
> > > +
> > > +/* We are under the virtio-vsock's vsock->rx_lock or vhost-vsock's vq->mutex
> > > + * lock.
> > > + */
> > > +void virtio_transport_recv_pkt(struct virtio_transport *t,
> > > + struct sk_buff *skb, struct net *net)
> > > +{
> > > + struct virtio_transport_rx_pkt_ctx ctx;
> > > + struct sockaddr_vm src, dst;
> > > + struct sock *sk;
> > > + bool free_pkt;
> > > +
> > > + virtio_transport_recv_pkt_init_addrs(skb, &src, &dst);
> > > + virtio_transport_trace_recv_pkt(skb, &src, &dst);
> > > +
> > > + sk = virtio_transport_recv_pkt_find_socket(skb, &src, &dst, net);
> > > + if (!sk) {
> > > + (void)virtio_transport_reset_no_sock(t, skb, net);
> > > + goto free_pkt;
> > > + }
> > > +
> > > + if (!skb_set_owner_sk_safe(skb, sk)) {
> > > + WARN_ONCE(1, "receiving vsock socket has sk_refcnt == 0\n");
> > > + goto free_pkt;
> > > + }
> > > +
> > > + lock_sock(sk);
> > > + ctx = (struct virtio_transport_rx_pkt_ctx) {
> > > + .net = net,
> > > + .src = &src,
> > > + .dst = &dst,
> > > + };
> > > + free_pkt = virtio_transport_recv_pkt_locked(t, skb, sk, &ctx);
> >
> > At this point the socket lookup succeeded with src/dst/net, why not just
> > pass sk which already has all of them?
> >
>
> If I understand this correctly, a successful lookup is not enough to
> recover all of this from sk. The lookup may fall back from the
> connected table to the bound
> table, so the packet source must still be validated under the socket
> lock; otherwise that check would become ineffective. The packet
> destination is also needed after
> a transport reset, and the RX namespace used for a reset reply is not
> necessarily sock_net(sk) in global mode. I’ll remove the context
> struct and pass src, dst, and
> net directly.
True that the lookup may fallback to the bound table, but this begs the
question, why bother with the bound table here? If a socket hasn't
landed in the connected table yet, then OP_RW is -EINVAL and we respond
with RST anyway... so I'd guess we shouldn't even be trying to batch for
those sockets.
For connected sockets, the sk has the destination (vsk->remote_addr)
needed by the reset. And yes, sock_net(sk) does not necessarily equal
the net ptr used for a reset reply in global mode, but we don't really
expect that for global mode in vsock, we only expect that
vsock_net_check_mode() rules are followed. In this case where
!net_eq(n0, n1), the RST reply will be routed correctly across
namespaces following global mode rules.
I could certainly be missing something and happy to be pointed to an
instance of sk being insufficient here. In general, I think its nice to
avoid new data structures if possible.
Best,
Bobby
next prev parent reply other threads:[~2026-10-13 17:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 14:22 [PATCH net-next v2 0/5] vsock/virtio: reduce RX per-packet socket overhead Jia Jia
2026-10-10 14:22 ` [PATCH net-next v2 1/5] vsock/virtio: split socket lookup from locked RX processing Jia Jia
2026-10-10 14:39 ` sashiko-bot
2026-10-11 14:25 ` netdev-bot+sashiko
2026-10-12 21:34 ` Bobby Eshleman
2026-10-13 3:24 ` Jia Jia
2026-10-12 22:02 ` Bobby Eshleman
2026-10-13 3:26 ` Jia Jia
2026-10-13 17:16 ` Bobby Eshleman [this message]
2026-10-10 14:22 ` [PATCH net-next v2 2/5] vsock/virtio: amortize RX socket locking for stream packets Jia Jia
2026-10-10 14:39 ` sashiko-bot
2026-10-11 14:25 ` netdev-bot+sashiko
2026-10-12 22:15 ` Bobby Eshleman
2026-10-13 3:28 ` Jia Jia
2026-10-13 17:31 ` Bobby Eshleman
2026-10-10 14:22 ` [PATCH net-next v2 3/5] vsock/virtio: reuse same-flow socket lookup in RX batches Jia Jia
2026-10-10 14:39 ` sashiko-bot
2026-10-12 22:17 ` Bobby Eshleman
2026-10-13 3:30 ` Jia Jia
2026-10-10 14:22 ` [PATCH net-next v2 4/5] vsock/virtio: coalesce RX write-space notifications in lock batches Jia Jia
2026-10-10 14:39 ` sashiko-bot
2026-10-10 14:22 ` [PATCH net-next v2 5/5] vsock/virtio: defer RX readable notifications until batch unlock Jia Jia
2026-10-10 14:39 ` sashiko-bot
2026-10-11 14:25 ` netdev-bot+sashiko
2026-10-12 5:51 ` Jia Jia
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=as5nfI0qfqD64dc1@devvm29614.prn0.facebook.com \
--to=bobbyeshleman@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=eperezma@redhat.com \
--cc=horms@kernel.org \
--cc=jasowangio@gmail.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=physicalmtea@gmail.com \
--cc=sgarzare@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.