All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sergio Lopez" <slp@redhat.com>
Cc: virtualization@lists.linux.dev, kvm@vger.kernel.org,
	bpf@vger.kernel.org, linux-hyperv@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH RFC v3 6/8] vsock: allow datagrams to use directional transports
Date: Fri, 13 Nov 2026 17:42:17 +0000	[thread overview]
Message-ID: <sashiko-outbox-213343@kernel.org> (raw)
In-Reply-To: <20261113-vsock-dgram-support-v3-6-1523c8e9b27e@redhat.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] vsock: local datagrams route to transport_g2h when loopback
  is unloaded
- [Medium] vsock: VMCI datagram sockets misroute CID_HOST and CID_ANY to
  loopback
--

commit 9eab4679f5d6926cf379df182996c2e8cd726902
Author: Sergio Lopez <slp@redhat.com>

vsock: allow datagrams to use directional transports

This commit enables datagram sockets to select directional and loopback
transports per destination while keeping a fallback transport as the
socket owner when needed, and unifies datagram receive queuing in the
core.

Link: https://lore.kernel.org/all/DMGNAV67LK3F.2FNLTD5NVHDEA@gmail.com/

> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> index aef5389eeca2c..e0d1a3e5d05cc 100644
> --- a/net/vmw_vsock/af_vsock.c
> +++ b/net/vmw_vsock/af_vsock.c
[ ... ]
> @@ -576,11 +579,56 @@ static bool vsock_use_local_transport(unsigned int remote_cid)
>  	if (remote_cid == VMADDR_CID_LOCAL)
>  		return true;
>  
> -	if (transport_g2h) {
> -		return remote_cid == transport_g2h->get_local_cid();
> -	} else {
> -		return remote_cid == VMADDR_CID_HOST;
> +	local_cid = transport_g2h ? transport_g2h->get_local_cid() :
> +		VMADDR_CID_HOST;
> +	/* A virtio device without a CID keeps the host loopback alias.
> +	 * Hyper-V has no numeric CID even while it is active, so CID_HOST
> +	 * must keep using its guest-to-host transport in that case.
> +	 */
> +	if (local_cid == VMADDR_CID_ANY && transport_g2h->dgram_transport_match)
> +		local_cid = VMADDR_CID_HOST;
> +
> +	return remote_cid == local_cid;
> +}
> +
> +/* Select a route without changing socket ownership. The caller holds
> + * vsock_register_mutex and pins the returned transport before releasing it.
> + */
> +static const struct vsock_transport *
> +vsock_select_transport(struct vsock_sock *vsk,
> +		       const struct sockaddr_vm *remote_addr,
> +		       const struct vsock_transport *dgram_owner,
> +		       bool *to_host)
> +{
> +	struct sock *sk = sk_vsock(vsk);
> +	u32 cid = remote_addr->svm_cid;
> +
> +	lockdep_assert_held(&vsock_register_mutex);
> +	*to_host = false;
> +
> +	if (vsock_use_local_transport(cid))
> +		return transport_local;
> +	if (cid <= VMADDR_CID_HOST ||
> +	    (remote_addr->svm_flags & VMADDR_FLAG_TO_HOST))
> +		return transport_g2h;

[Severity: Medium]
Can vsock_select_transport() route VMADDR_CID_LOCAL datagrams to
transport_g2h when transport_local is not registered?

When transport_local is NULL, vsock_use_local_transport(VMADDR_CID_LOCAL)
returns false and cid <= VMADDR_CID_HOST (1 <= 2) matches, returning
transport_g2h instead of NULL. Because vsock_dgram_resolve_cid() also
maps VMADDR_CID_ANY to VMADDR_CID_LOCAL whenever
owner->dgram_transport_match is set, datagram connect() and sendmsg() to
VMADDR_CID_LOCAL or VMADDR_CID_ANY transmit local packets to the host (or
fall back to the VMCI owner) instead of failing with -ENODEV. When
vsock.g2h_fallback is enabled without transport_local, connecting a
datagram socket to the guest's own CID also succeeds via transport_g2h
even though subsequent sends fail in virtio_transport_send_pkt().

[ ... ]

> @@ -1461,6 +1645,27 @@ static int vsock_read_skb(struct sock *sk, skb_read_actor_t read_actor)
>  	return vsk->transport->read_skb(vsk, read_actor);
>  }
>  
> +static int vsock_dgram_resolve_cid(struct vsock_sock *vsk,
> +				   struct sockaddr_vm *remote_addr,
> +				   bool *vmci_self)
> +{
> +	const struct vsock_transport *owner = vsk->transport;
> +
> +	if (remote_addr->svm_cid != VMADDR_CID_ANY)
> +		return 0;
> +
> +	mutex_lock(&vsock_register_mutex);
> +	if (transport_local || owner->dgram_transport_match) {
> +		remote_addr->svm_cid = VMADDR_CID_LOCAL;
> +	} else {
> +		remote_addr->svm_cid = owner->get_local_cid();
> +		*vmci_self = owner->dgram_fallback;
> +	}
> +	mutex_unlock(&vsock_register_mutex);
> +
> +	return remote_addr->svm_cid == VMADDR_CID_ANY ? -EADDRNOTAVAIL : 0;
> +}

[Severity: Medium]
Does this misroute VMCI datagrams onto loopback when vsock_loopback is
loaded?

On a VMCI guest where virtio_transport is loaded without an active
virtio-vsock device (or transport_g2h is NULL),
vsock_use_local_transport(VMADDR_CID_HOST) returns true, so
vsock_select_transport() routes VMADDR_CID_HOST datagrams to
transport_local instead of falling back to the VMCI owner. In addition, if
a VMCI socket is bound to VMCI's local CID and sends or connects to
VMADDR_CID_ANY while transport_local is registered,
vsock_dgram_resolve_cid() resolves the destination to VMADDR_CID_LOCAL and
vsock_dgram_get_transport() skips the fallback to owner because
transport->get_local_cid() == VMADDR_CID_LOCAL, failing with
-EADDRNOTAVAIL when vsk->local_addr.svm_cid does not match loopback.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113-vsock-dgram-support-v3-0-1523c8e9b27e@redhat.com?part=6

  reply	other threads:[~2026-11-13 17:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 17:15 [PATCH RFC v3 0/8] vsock: add datagram support to virtio and vhost Sergio Lopez
2026-11-13 17:15 ` [PATCH RFC v3 1/8] vsock: expose the core port allocator to transports Sergio Lopez
2026-11-13 17:22   ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 2/8] vsock: report datagram receive and send queue state Sergio Lopez
2026-11-13 17:25   ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 3/8] vsock/virtio: implement the datagram data path Sergio Lopez
2026-11-13 17:47   ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 4/8] vsock/virtio: negotiate datagram support on the guest Sergio Lopez
2026-11-13 17:35   ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 5/8] vhost/vsock: negotiate datagram support with guests Sergio Lopez
2026-11-13 17:34   ` sashiko-bot
2026-11-13 17:15 ` [PATCH RFC v3 6/8] vsock: allow datagrams to use directional transports Sergio Lopez
2026-11-13 17:42   ` sashiko-bot [this message]
2026-11-13 17:15 ` [PATCH RFC v3 7/8] vsock: fragment datagrams across receive buffers Sergio Lopez
2026-11-13 17:34   ` sashiko-bot
2026-11-13 22:37   ` Bobby Eshleman
2026-11-13 17:15 ` [PATCH RFC v3 8/8] vsock: add datagram tests to vsock_test Sergio Lopez
2026-11-13 17:51   ` sashiko-bot
2026-11-13 22:18 ` [PATCH RFC v3 0/8] vsock: add datagram support to virtio and vhost 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=sashiko-outbox-213343@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=eperezma@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=slp@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 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.