All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bobby Eshleman <bobbyeshleman@gmail.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: "Shuah Khan" <shuah@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	"Wei Liu" <wei.liu@kernel.org>,
	"Dexuan Cui" <decui@microsoft.com>,
	"Bryan Tan" <bryan-bt.tan@broadcom.com>,
	"Vishnu Dasa" <vishnu.dasa@broadcom.com>,
	"Broadcom internal kernel review list"
	<bcm-kernel-feedback-list@broadcom.com>,
	virtualization@lists.linux.dev, netdev@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, linux-hyperv@vger.kernel.org,
	berrange@redhat.com, "Bobby Eshleman" <bobbyeshleman@meta.com>
Subject: Re: [PATCH net-next v5 3/9] vsock: add netns to vsock core
Date: Tue, 2 Sep 2025 10:10:00 -0700	[thread overview]
Message-ID: <aLck6IIS3AiDJZPg@devvm6216.cco0.facebook.com> (raw)
In-Reply-To: <gncp3ynz3inufzex64sla2ia3stjsen2n3hwhfuykdhmpuuegu@7hk5q2hjfxkv>

On Tue, Sep 02, 2025 at 05:39:10PM +0200, Stefano Garzarella wrote:
> On Wed, Aug 27, 2025 at 05:31:31PM -0700, Bobby Eshleman wrote:
> > From: Bobby Eshleman <bobbyeshleman@meta.com>

...

> > {
> > 	enum vsock_net_mode ret;
> > diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
> > index 0538948d5fd9..68a8875c8106 100644
> > --- a/net/vmw_vsock/af_vsock.c
> > +++ b/net/vmw_vsock/af_vsock.c
> > @@ -83,6 +83,24 @@
> >  *   TCP_ESTABLISHED - connected
> >  *   TCP_CLOSING - disconnecting
> >  *   TCP_LISTEN - listening
> > + *
> > + * - Namespaces in vsock support two different modes configured
> > + *   through /proc/sys/net/vsock/ns_mode. The modes are "local" and "global".
> > + *   Each mode defines how the namespace interacts with CIDs.
> > + *   /proc/sys/net/vsock/ns_mode is write-once, so that it may be configured
> > + *   and locked down by a namespace manager. The default is "global". The mode
> > + *   is set per-namespace.
> > + *
> > + *   The modes affect the allocation and accessibility of CIDs as follows:
> > + *   - global - aka fully public
> > + *      - CID allocation draws from the public pool
> > + *      - AF_VSOCK sockets may reach any CID allocated from the public pool
> > + *      - AF_VSOCK sockets may not reach CIDs allocated from private
> > pools
> 
> Should we define what public and private pools are?
> 
> What I found difficult to understand was the allocation of CIDs, meaning I
> had to reread it two or three times to perhaps understand it.
> 
> IIUC, netns with mode=global can only allocate public CIDs, while netns with
> mode=local can only allocate private CIDs, right?
> 

Correct.

> Perhaps we should first better define how CIDs are allocated and then
> explain the interaction between them.
> 

Makes sense, I'll clarify that.

> > + *
> > + *   - local - aka fully private
> > + *     - CID allocation draws only from the private pool, does not affect public pool
> > + *     - AF_VSOCK sockets may only reach CIDs from the private pool
> > + *     - AF_VSOCK sockets may not reach CIDs allocated from outside the pool
> 
> Why using "may" ? I mean, can be cases when this is not true?
> 


Good point, will change to stronger language since it is always true.

[...]

> > 
> > @@ -2636,6 +2670,137 @@ static struct miscdevice vsock_device = {
> > 	.fops		= &vsock_device_ops,
> > };
> > 
> > +#define VSOCK_NET_MODE_STRING_MAX 7
> > +
> > +static int vsock_net_mode_string(const struct ctl_table *table, int write,
> > +				 void *buffer, size_t *lenp, loff_t *ppos)
> > +{
> > +	char buf[VSOCK_NET_MODE_STRING_MAX] = {0};
> 
> Can we change `buf` name?
> 
> I find it confusing to have both a `buffer` variable and a `buf` variable in
> the same function.
> 

Makes sense, will do.

> > +	enum vsock_net_mode mode;
> > +	struct ctl_table tmp;
> > +	struct net *net;
> > +	const char *p;
> 
> Can we move `p` declaration in the `if (!write) {` block?
> 

yes.

> > +	int ret;
> > +
> > +	if (!table->data || !table->maxlen || !*lenp) {
> > +		*lenp = 0;
> > +		return 0;
> > +	}
> > +
> > +	net = current->nsproxy->net_ns;
> > +	tmp = *table;
> > +	tmp.data = buf;
> > +
> > +	if (!write) {
> > +		mode = vsock_net_mode(net);
> > +
> > +		if (mode == VSOCK_NET_MODE_GLOBAL) {
> > +			p = "global";
> > +		} else if (mode == VSOCK_NET_MODE_LOCAL) {
> > +			p = "local";
> > +		} else {
> > +			WARN_ONCE(true, "netns has invalid vsock mode");
> > +			*lenp = 0;
> > +			return 0;
> > +		}
> > +
> > +		strscpy(buf, p, sizeof(buf));
> > +		tmp.maxlen = strlen(p);
> > +	}
> > +
> > +	ret = proc_dostring(&tmp, write, buffer, lenp, ppos);
> > +	if (ret)
> > +		return ret;
> > +
> > +	if (write) {
> > +		if (!strncmp(buffer, "global", 6))
> 
> Are we sure that the `buffer` is at least 6 bytes long and NULL-terminated?
> 
> Maybe we can just check that `lenp <= sizeof(buf)`...
> 
> Should we add macros for "global" and "local" ?
> 

That all sounds reasonable. IIRC I tested with some garbage writes, but might
as well err on the side of caution.

> 
> > +			mode = VSOCK_NET_MODE_GLOBAL;
> > +		else if (!strncmp(buffer, "local", 5))
> > +			mode = VSOCK_NET_MODE_LOCAL;
> > +		else
> > +			return -EINVAL;
> > +
> > +		if (!vsock_net_write_mode(net, mode))
> > +			return -EPERM;
> > +	}
> > +
> > +	return 0;
> > +}
> > +

...


Thanks for the review!

Best,
Bobby

  reply	other threads:[~2025-09-02 17:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-28  0:31 [PATCH net-next v5 0/9] vsock: add namespace support to vhost-vsock Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 1/9] vsock: a per-net vsock NS mode state Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 2/9] vsock: add net to vsock skb cb Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 3/9] vsock: add netns to vsock core Bobby Eshleman
2025-09-02 15:39   ` Stefano Garzarella
2025-09-02 17:10     ` Bobby Eshleman [this message]
2025-08-28  0:31 ` [PATCH net-next v5 4/9] vsock/loopback: add netns support Bobby Eshleman
2025-08-28 10:35   ` kernel test robot
2025-09-02 15:39   ` Stefano Garzarella
2025-09-02 18:09     ` Bobby Eshleman
2025-09-03 15:10       ` Stefano Garzarella
2025-09-04 16:57         ` Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 5/9] vsock/virtio: add netns to virtio transport common Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 6/9] vhost/vsock: add netns support Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 7/9] selftests/vsock: improve logging in vmtest.sh Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 8/9] selftests/vsock: invoke vsock_test through helpers Bobby Eshleman
2025-08-28  0:31 ` [PATCH net-next v5 9/9] selftests/vsock: add namespace tests Bobby Eshleman
2025-09-02 15:40   ` Stefano Garzarella
2025-09-02 18:10     ` 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=aLck6IIS3AiDJZPg@devvm6216.cco0.facebook.com \
    --to=bobbyeshleman@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=berrange@redhat.com \
    --cc=bobbyeshleman@meta.com \
    --cc=bryan-bt.tan@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=edumazet@google.com \
    --cc=eperezma@redhat.com \
    --cc=haiyangz@microsoft.com \
    --cc=horms@kernel.org \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@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=sgarzare@redhat.com \
    --cc=shuah@kernel.org \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=vishnu.dasa@broadcom.com \
    --cc=wei.liu@kernel.org \
    --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.