Re: [PATCH net-next 4/6] selftests/vsock: add a helper to assign the g2h device to a netns

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 0 · Low: 2

- [Low] Concern (validated as a FALSE POSITIVE): the new helper binary
  vsock_assign_g2h_netns was claimed to be built and installed with no…
- [Low] Documentation/admin-guide/sysctl/net.rst (lines 518-534, added by
  "vsock: add IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS") describes G2H…

--

selftests/vsock: add a helper to assign the g2h device to a netns

This adds a small userspace helper, vsock_assign_g2h_netns, that opens
/dev/vsock and issues IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS so shell based
tests can move the guest vsock device into the caller's network
namespace. The helper exits with the ioctl errno and is added to
TEST_GEN_FILES and .gitignore.

> diff --git a/tools/testing/selftests/vsock/vsock_assign_g2h_netns.c b/tools/testing/selftests/vsock/vsock_assign_g2h_netns.c
> new file mode 100644
> index 000000000000..6f15629af607
> --- /dev/null
> +++ b/tools/testing/selftests/vsock/vsock_assign_g2h_netns.c
> @@ -0,0 +1,45 @@

[ ... ]

> +	ret = ioctl(fd, IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS);
> +	if (ret < 0) {
> +		ret = errno;
> +		fprintf(stderr,
> +			"IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS: %s (errno %d)\n",
> +			strerror(errno), errno);
> +	}

[Severity: Low]
While looking at what errnos a caller of this helper can expect, the
documentation added earlier in the series for this ioctl reads as if the
move always happens.  From the vsock section of
Documentation/admin-guide/sysctl/net.rst:

  In a guest, the vsock device owned by the guest-to-host (G2H) transport
  belongs to one network namespace at a time.  The
  IOCTL_VM_SOCKETS_ASSIGN_G2H_NETNS ioctl on /dev/vsock moves it to the
  namespace of the calling process, which requires CAP_NET_ADMIN in the
  initial user namespace.

The uapi comment above the define in include/uapi/linux/vm_sockets.h is
similarly unqualified:

  /* Assign the guest's vsock device to the network namespace of the calling
   * process. Requires CAP_NET_ADMIN in the initial user namespace. To undo an
   * assignment, assign the device to the initial network namespace.
   */

The implementation only allows the move for transports that opt in.  In
net/vmw_vsock/af_vsock.c, vsock_g2h_net_assign() refuses otherwise:

	} else if (!vsock_g2h_netns_assignable()) {
		ret = -EOPNOTSUPP;

and vsock_g2h_netns_assignable() requires the callback:

	return transport_g2h && transport_g2h->netns_assign_allow &&
	       transport_g2h->netns_assign_allow();

Grepping net/vmw_vsock/ shows netns_assign_allow is only provided by
virtio_transport.c (virtio_transport_netns_assign_allow()).
hyperv_transport.c registers with vsock_core_register(&hvs_transport,
VSOCK_TRANSPORT_F_G2H) and vmci_transport.c sets features =
VSOCK_TRANSPORT_F_G2H, and neither defines the callback.

So on a Hyper-V or VMCI guest, does this ioctl always fail with
-EOPNOTSUPP even for a CAP_NET_ADMIN caller, contrary to what net.rst and
the uapi comment describe?  Would it be worth saying in both places that
assignment is transport dependent and that transports which do not opt in
return -EOPNOTSUPP?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260902-vsock-guest-ns-v1-0-9995383e9a8b%40meta.com