Linux-HyperV Archive on lore.kernel.org
 help / color / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: netdev@vger.kernel.org, Sasha Levin <sashal@kernel.org>,
	linux-hyperv@vger.kernel.org,
	Stephen Hemminger <sthemmin@microsoft.com>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Dexuan Cui <decui@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jorgen Hansen <jhansen@vmware.com>
Subject: Re: [RFC PATCH 07/13] vsock: handle buffer_size sockopts in the core
Date: Thu, 10 Oct 2019 11:32:54 +0200
Message-ID: <20191010093254.aluys4hpsfcepb42@steredhat> (raw)
In-Reply-To: <20191009123026.GH5747@stefanha-x1.localdomain>

On Wed, Oct 09, 2019 at 01:30:26PM +0100, Stefan Hajnoczi wrote:
> On Fri, Sep 27, 2019 at 01:26:57PM +0200, Stefano Garzarella wrote:
> > @@ -140,18 +145,11 @@ struct vsock_transport {
> >  		struct vsock_transport_send_notify_data *);
> >  	int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t,
> >  		struct vsock_transport_send_notify_data *);
> > +	int (*notify_buffer_size)(struct vsock_sock *, u64 *);
> 
> Is ->notify_buffer_size() called under lock_sock(sk)?  If yes, please
> document it.

Yes, it is. I'll document it!

> 
> > +static void vsock_update_buffer_size(struct vsock_sock *vsk,
> > +				     const struct vsock_transport *transport,
> > +				     u64 val)
> > +{
> > +	if (val > vsk->buffer_max_size)
> > +		val = vsk->buffer_max_size;
> > +
> > +	if (val < vsk->buffer_min_size)
> > +		val = vsk->buffer_min_size;
> > +
> > +	if (val != vsk->buffer_size &&
> > +	    transport && transport->notify_buffer_size)
> > +		transport->notify_buffer_size(vsk, &val);
> 
> Why does this function return an int if we don't check the return value?
> 

Copy and past :-(
I'll fix it returning void since I don't think it can fail.

> > diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> > index fc046c071178..bac9e7430a2e 100644
> > --- a/net/vmw_vsock/virtio_transport_common.c
> > +++ b/net/vmw_vsock/virtio_transport_common.c
> > @@ -403,17 +403,13 @@ int virtio_transport_do_socket_init(struct vsock_sock *vsk,
> >  	if (psk) {
> >  		struct virtio_vsock_sock *ptrans = psk->trans;
> >  
> > -		vvs->buf_size	= ptrans->buf_size;
> > -		vvs->buf_size_min = ptrans->buf_size_min;
> > -		vvs->buf_size_max = ptrans->buf_size_max;
> >  		vvs->peer_buf_alloc = ptrans->peer_buf_alloc;
> > -	} else {
> > -		vvs->buf_size = VIRTIO_VSOCK_DEFAULT_BUF_SIZE;
> > -		vvs->buf_size_min = VIRTIO_VSOCK_DEFAULT_MIN_BUF_SIZE;
> > -		vvs->buf_size_max = VIRTIO_VSOCK_DEFAULT_MAX_BUF_SIZE;
> >  	}
> >  
> > -	vvs->buf_alloc = vvs->buf_size;
> > +	if (vsk->buffer_size > VIRTIO_VSOCK_MAX_BUF_SIZE)
> > +		vsk->buffer_size = VIRTIO_VSOCK_MAX_BUF_SIZE;
> 
> Hmm...this could be outside the [min, max] range.  I'm not sure how much
> it matters.

The core guarantees that vsk->buffer_size is <= of the max, so since we are
lowering it, the max should be respected. For the min you are right,
but I think this limit is stricter than the min set by the user.

> 
> Another issue is that this patch drops the VIRTIO_VSOCK_MAX_BUF_SIZE
> limit that used to be enforced by virtio_transport_set_buffer_size().
> Now the limit is only applied at socket init time.  If the buffer size
> is changed later then VIRTIO_VSOCK_MAX_BUF_SIZE can be exceeded.  If
> that doesn't matter, why even bother with VIRTIO_VSOCK_MAX_BUF_SIZE
> here?
> 

The .notify_buffer_size() should avoid this issue, since it allows the
transport to limit the buffer size requested after the initialization.

But again the min set by the user can not be respected and in the
previous implementation we forced it to VIRTIO_VSOCK_MAX_BUF_SIZE.

Now we don't limit the min, but we guarantee only that vsk->buffer_size
is lower than VIRTIO_VSOCK_MAX_BUF_SIZE.

Can that be an acceptable compromise?

Thanks,
Stefano

  reply index

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27 11:26 [RFC PATCH 00/13] vsock: add multi-transports support Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 01/13] vsock/vmci: remove unused VSOCK_DEFAULT_CONNECT_TIMEOUT Stefano Garzarella
2019-10-09 11:41   ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 02/13] vsock: remove vm_sockets_get_local_cid() Stefano Garzarella
2019-10-09 11:42   ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 03/13] vsock: remove include/linux/vm_sockets.h file Stefano Garzarella
2019-10-09 11:43   ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 04/13] vsock: add 'transport' member in the struct vsock_sock Stefano Garzarella
2019-10-09 11:46   ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 05/13] vsock/virtio: add transport parameter to the virtio_transport_reset_no_sock() Stefano Garzarella
2019-10-09 11:52   ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 06/13] vsock: add 'struct vsock_sock *' param to vsock_core_get_transport() Stefano Garzarella
2019-10-09 11:54   ` Stefan Hajnoczi
2019-10-10  8:50     ` Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 07/13] vsock: handle buffer_size sockopts in the core Stefano Garzarella
2019-10-03 20:11   ` Dexuan Cui
2019-10-09 12:30   ` Stefan Hajnoczi
2019-10-10  9:32     ` Stefano Garzarella [this message]
2019-10-11  8:27       ` Stefan Hajnoczi
2019-10-11  8:51         ` Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 08/13] vsock: move vsock_insert_unbound() in the vsock_create() Stefano Garzarella
2019-10-03 20:17   ` Dexuan Cui
2019-10-09 12:34   ` Stefan Hajnoczi
2019-10-10  9:52     ` Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 09/13] hv_sock: set VMADDR_CID_HOST in the hvs_remote_addr_init() Stefano Garzarella
2019-10-03 19:36   ` Dexuan Cui
2019-10-09 12:35   ` Stefan Hajnoczi
2019-09-27 11:27 ` [RFC PATCH 10/13] vsock: add multi-transports support Stefano Garzarella
2019-10-09 13:11   ` Stefan Hajnoczi
2019-10-10 12:55     ` Stefano Garzarella
2019-09-27 11:27 ` [RFC PATCH 11/13] vsock: add 'transport_hg' to handle g2h\h2g transports Stefano Garzarella
2019-10-09  9:44   ` Stefano Garzarella
2019-10-09 13:16   ` Stefan Hajnoczi
2019-10-10 13:04     ` Stefano Garzarella
2019-09-27 11:27 ` [RFC PATCH 12/13] vsock: prevent transport modules unloading Stefano Garzarella
2019-10-09 13:28   ` Stefan Hajnoczi
2019-09-27 11:27 ` [RFC PATCH 13/13] vsock: fix bind() behaviour taking care of CID Stefano Garzarella
2019-10-09 13:29   ` Stefan Hajnoczi
2019-10-04  0:04 ` [RFC PATCH 00/13] vsock: add multi-transports support Dexuan Cui
2019-10-04  9:16   ` Stefano Garzarella
2019-10-09 13:29 ` Stefan Hajnoczi
2019-10-10  8:45   ` Stefano Garzarella

Reply instructions:

You may reply publically 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=20191010093254.aluys4hpsfcepb42@steredhat \
    --to=sgarzare@redhat.com \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=jhansen@vmware.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=sthemmin@microsoft.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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

Linux-HyperV Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-hyperv/0 linux-hyperv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-hyperv linux-hyperv/ https://lore.kernel.org/linux-hyperv \
		linux-hyperv@vger.kernel.org linux-hyperv@archiver.kernel.org
	public-inbox-index linux-hyperv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-hyperv


AGPL code for this site: git clone https://public-inbox.org/ public-inbox