Linux-HyperV List
 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: 12+ 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:15 ` [PATCH RFC v3 2/8] vsock: report datagram receive and send queue state Sergio Lopez
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:15 ` [PATCH RFC v3 5/8] vhost/vsock: negotiate datagram support with guests Sergio Lopez
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:15 ` [PATCH RFC v3 8/8] vsock: add datagram tests to vsock_test Sergio Lopez
2026-11-13 17:51   ` sashiko-bot

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox