All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: Arseny Krasnov <arseny.krasnov@kaspersky.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Jorgen Hansen <jhansen@vmware.com>,
	Colin Ian King <colin.king@canonical.com>,
	Andra Paraschiv <andraprs@amazon.com>,
	Jeff Vander Stoep <jeffv@google.com>,
	kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	stsp2@yandex.ru, oxffffaa@gmail.com
Subject: Re: [RFC PATCH v4 03/17] af_vsock: separate receive data loop
Date: Thu, 11 Feb 2021 12:37:53 +0100	[thread overview]
Message-ID: <20210211113753.o4zco3yromuxpvo2@steredhat> (raw)
In-Reply-To: <20210207151508.804615-1-arseny.krasnov@kaspersky.com>

On Sun, Feb 07, 2021 at 06:15:05PM +0300, Arseny Krasnov wrote:
>This moves STREAM specific data receive logic to dedicated function:
>'__vsock_stream_recvmsg()', while checks that will be same for both
>types of socket are in shared function: 'vsock_connectible_recvmsg()'.
>
>Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>
>---
> net/vmw_vsock/af_vsock.c | 117 +++++++++++++++++++++++----------------
> 1 file changed, 68 insertions(+), 49 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 38927695786f..66c8a932f49b 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -1898,65 +1898,22 @@ static int vsock_wait_data(struct sock *sk, struct wait_queue_entry *wait,
> 	return err;
> }
>
>-static int
>-vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>-			  int flags)
>+static int __vsock_stream_recvmsg(struct sock *sk, struct msghdr *msg,
>+				  size_t len, int flags)
> {
>-	struct sock *sk;
>-	struct vsock_sock *vsk;
>+	struct vsock_transport_recv_notify_data recv_data;
> 	const struct vsock_transport *transport;
>-	int err;
>-	size_t target;
>+	struct vsock_sock *vsk;
> 	ssize_t copied;
>+	size_t target;
> 	long timeout;
>-	struct vsock_transport_recv_notify_data recv_data;
>+	int err;
>
> 	DEFINE_WAIT(wait);
>
>-	sk = sock->sk;
> 	vsk = vsock_sk(sk);
>-	err = 0;
>-
>-	lock_sock(sk);
>-
> 	transport = vsk->transport;
>
>-	if (!transport || sk->sk_state != TCP_ESTABLISHED) {
>-		/* Recvmsg is supposed to return 0 if a peer performs an
>-		 * orderly shutdown. Differentiate between that case and when a
>-		 * peer has not connected or a local shutdown occured with the
>-		 * SOCK_DONE flag.
>-		 */
>-		if (sock_flag(sk, SOCK_DONE))
>-			err = 0;
>-		else
>-			err = -ENOTCONN;
>-
>-		goto out;
>-	}
>-
>-	if (flags & MSG_OOB) {
>-		err = -EOPNOTSUPP;
>-		goto out;
>-	}
>-
>-	/* We don't check peer_shutdown flag here since peer may actually shut
>-	 * down, but there can be data in the queue that a local socket can
>-	 * receive.
>-	 */
>-	if (sk->sk_shutdown & RCV_SHUTDOWN) {
>-		err = 0;
>-		goto out;
>-	}
>-
>-	/* It is valid on Linux to pass in a zero-length receive buffer.  This
>-	 * is not an error.  We may as well bail out now.
>-	 */
>-	if (!len) {
>-		err = 0;
>-		goto out;
>-	}
>-
> 	/* We must not copy less than target bytes into the user's buffer
> 	 * before returning successfully, so we wait for the consume queue to
> 	 * have that much data to consume before dequeueing.  Note that this

At the end of __vsock_stream_recvmsg() you are calling release_sock(sk) 
and it's wrong since we are releasing it in vsock_connectible_recvmsg().

Please fix it.

>@@ -2020,6 +1977,68 @@ vsock_connectible_recvmsg(struct socket *sock, 
>struct msghdr *msg, size_t len,
> 	return err;
> }
>
>+static int
>+vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>+			  int flags)
>+{
>+	struct sock *sk;
>+	struct vsock_sock *vsk;
>+	const struct vsock_transport *transport;
>+	int err;
>+
>+	DEFINE_WAIT(wait);
>+
>+	sk = sock->sk;
>+	vsk = vsock_sk(sk);
>+	err = 0;
>+
>+	lock_sock(sk);
>+
>+	transport = vsk->transport;
>+
>+	if (!transport || sk->sk_state != TCP_ESTABLISHED) {
>+		/* Recvmsg is supposed to return 0 if a peer performs an
>+		 * orderly shutdown. Differentiate between that case and when a
>+		 * peer has not connected or a local shutdown occurred with the
>+		 * SOCK_DONE flag.
>+		 */
>+		if (sock_flag(sk, SOCK_DONE))
>+			err = 0;
>+		else
>+			err = -ENOTCONN;
>+
>+		goto out;
>+	}
>+
>+	if (flags & MSG_OOB) {
>+		err = -EOPNOTSUPP;
>+		goto out;
>+	}
>+
>+	/* We don't check peer_shutdown flag here since peer may actually shut
>+	 * down, but there can be data in the queue that a local socket can
>+	 * receive.
>+	 */
>+	if (sk->sk_shutdown & RCV_SHUTDOWN) {
>+		err = 0;
>+		goto out;
>+	}
>+
>+	/* It is valid on Linux to pass in a zero-length receive buffer.  This
>+	 * is not an error.  We may as well bail out now.
>+	 */
>+	if (!len) {
>+		err = 0;
>+		goto out;
>+	}
>+
>+	err = __vsock_stream_recvmsg(sk, msg, len, flags);
>+
>+out:
>+	release_sock(sk);
>+	return err;
>+}
>+

The rest of the patch LGTM.

Stefano


WARNING: multiple messages have this Message-ID (diff)
From: Stefano Garzarella <sgarzare@redhat.com>
To: Arseny Krasnov <arseny.krasnov@kaspersky.com>
Cc: Andra Paraschiv <andraprs@amazon.com>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Jeff Vander Stoep <jeffv@google.com>,
	stsp2@yandex.ru, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, oxffffaa@gmail.com,
	netdev@vger.kernel.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Colin Ian King <colin.king@canonical.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jorgen Hansen <jhansen@vmware.com>
Subject: Re: [RFC PATCH v4 03/17] af_vsock: separate receive data loop
Date: Thu, 11 Feb 2021 12:37:53 +0100	[thread overview]
Message-ID: <20210211113753.o4zco3yromuxpvo2@steredhat> (raw)
In-Reply-To: <20210207151508.804615-1-arseny.krasnov@kaspersky.com>

On Sun, Feb 07, 2021 at 06:15:05PM +0300, Arseny Krasnov wrote:
>This moves STREAM specific data receive logic to dedicated function:
>'__vsock_stream_recvmsg()', while checks that will be same for both
>types of socket are in shared function: 'vsock_connectible_recvmsg()'.
>
>Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>
>---
> net/vmw_vsock/af_vsock.c | 117 +++++++++++++++++++++++----------------
> 1 file changed, 68 insertions(+), 49 deletions(-)
>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 38927695786f..66c8a932f49b 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -1898,65 +1898,22 @@ static int vsock_wait_data(struct sock *sk, struct wait_queue_entry *wait,
> 	return err;
> }
>
>-static int
>-vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>-			  int flags)
>+static int __vsock_stream_recvmsg(struct sock *sk, struct msghdr *msg,
>+				  size_t len, int flags)
> {
>-	struct sock *sk;
>-	struct vsock_sock *vsk;
>+	struct vsock_transport_recv_notify_data recv_data;
> 	const struct vsock_transport *transport;
>-	int err;
>-	size_t target;
>+	struct vsock_sock *vsk;
> 	ssize_t copied;
>+	size_t target;
> 	long timeout;
>-	struct vsock_transport_recv_notify_data recv_data;
>+	int err;
>
> 	DEFINE_WAIT(wait);
>
>-	sk = sock->sk;
> 	vsk = vsock_sk(sk);
>-	err = 0;
>-
>-	lock_sock(sk);
>-
> 	transport = vsk->transport;
>
>-	if (!transport || sk->sk_state != TCP_ESTABLISHED) {
>-		/* Recvmsg is supposed to return 0 if a peer performs an
>-		 * orderly shutdown. Differentiate between that case and when a
>-		 * peer has not connected or a local shutdown occured with the
>-		 * SOCK_DONE flag.
>-		 */
>-		if (sock_flag(sk, SOCK_DONE))
>-			err = 0;
>-		else
>-			err = -ENOTCONN;
>-
>-		goto out;
>-	}
>-
>-	if (flags & MSG_OOB) {
>-		err = -EOPNOTSUPP;
>-		goto out;
>-	}
>-
>-	/* We don't check peer_shutdown flag here since peer may actually shut
>-	 * down, but there can be data in the queue that a local socket can
>-	 * receive.
>-	 */
>-	if (sk->sk_shutdown & RCV_SHUTDOWN) {
>-		err = 0;
>-		goto out;
>-	}
>-
>-	/* It is valid on Linux to pass in a zero-length receive buffer.  This
>-	 * is not an error.  We may as well bail out now.
>-	 */
>-	if (!len) {
>-		err = 0;
>-		goto out;
>-	}
>-
> 	/* We must not copy less than target bytes into the user's buffer
> 	 * before returning successfully, so we wait for the consume queue to
> 	 * have that much data to consume before dequeueing.  Note that this

At the end of __vsock_stream_recvmsg() you are calling release_sock(sk) 
and it's wrong since we are releasing it in vsock_connectible_recvmsg().

Please fix it.

>@@ -2020,6 +1977,68 @@ vsock_connectible_recvmsg(struct socket *sock, 
>struct msghdr *msg, size_t len,
> 	return err;
> }
>
>+static int
>+vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
>+			  int flags)
>+{
>+	struct sock *sk;
>+	struct vsock_sock *vsk;
>+	const struct vsock_transport *transport;
>+	int err;
>+
>+	DEFINE_WAIT(wait);
>+
>+	sk = sock->sk;
>+	vsk = vsock_sk(sk);
>+	err = 0;
>+
>+	lock_sock(sk);
>+
>+	transport = vsk->transport;
>+
>+	if (!transport || sk->sk_state != TCP_ESTABLISHED) {
>+		/* Recvmsg is supposed to return 0 if a peer performs an
>+		 * orderly shutdown. Differentiate between that case and when a
>+		 * peer has not connected or a local shutdown occurred with the
>+		 * SOCK_DONE flag.
>+		 */
>+		if (sock_flag(sk, SOCK_DONE))
>+			err = 0;
>+		else
>+			err = -ENOTCONN;
>+
>+		goto out;
>+	}
>+
>+	if (flags & MSG_OOB) {
>+		err = -EOPNOTSUPP;
>+		goto out;
>+	}
>+
>+	/* We don't check peer_shutdown flag here since peer may actually shut
>+	 * down, but there can be data in the queue that a local socket can
>+	 * receive.
>+	 */
>+	if (sk->sk_shutdown & RCV_SHUTDOWN) {
>+		err = 0;
>+		goto out;
>+	}
>+
>+	/* It is valid on Linux to pass in a zero-length receive buffer.  This
>+	 * is not an error.  We may as well bail out now.
>+	 */
>+	if (!len) {
>+		err = 0;
>+		goto out;
>+	}
>+
>+	err = __vsock_stream_recvmsg(sk, msg, len, flags);
>+
>+out:
>+	release_sock(sk);
>+	return err;
>+}
>+

The rest of the patch LGTM.

Stefano

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2021-02-11 11:58 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-07 15:12 [RFC PATCH v4 00/17] virtio/vsock: introduce SOCK_SEQPACKET support Arseny Krasnov
2021-02-07 15:14 ` [RFC PATCH v4 01/17] af_vsock: update functions for connectible socket Arseny Krasnov
2021-02-11 10:52   ` Stefano Garzarella
2021-02-11 10:52     ` Stefano Garzarella
2021-02-07 15:14 ` [RFC PATCH v4 02/17] af_vsock: separate wait data loop Arseny Krasnov
2021-02-11 11:24   ` Stefano Garzarella
2021-02-11 11:24     ` Stefano Garzarella
2021-02-11 15:11   ` Jorgen Hansen
2021-02-11 15:11     ` Jorgen Hansen
2021-02-16  6:58     ` Arseny Krasnov
2021-02-07 15:15 ` [RFC PATCH v4 03/17] af_vsock: separate receive " Arseny Krasnov
2021-02-11 11:37   ` Stefano Garzarella [this message]
2021-02-11 11:37     ` Stefano Garzarella
2021-02-07 15:15 ` [RFC PATCH v4 04/17] af_vsock: implement SEQPACKET receive loop Arseny Krasnov
2021-02-11 11:47   ` Stefano Garzarella
2021-02-11 11:47     ` Stefano Garzarella
2021-02-07 15:15 ` [RFC PATCH v4 05/17] af_vsock: separate wait space loop Arseny Krasnov
2021-02-07 16:58   ` kernel test robot
2021-02-11 12:14   ` Stefano Garzarella
2021-02-11 12:14     ` Stefano Garzarella
2021-02-07 15:15 ` [RFC PATCH v4 06/17] af_vsock: implement send logic for SEQPACKET Arseny Krasnov
2021-02-11 12:17   ` Stefano Garzarella
2021-02-11 12:17     ` Stefano Garzarella
2021-02-07 15:16 ` [RFC PATCH v4 07/17] af_vsock: rest of SEQPACKET support Arseny Krasnov
2021-02-11 12:27   ` Stefano Garzarella
2021-02-11 12:27     ` Stefano Garzarella
2021-02-15  9:11     ` Arseny Krasnov
2021-02-07 15:16 ` [RFC PATCH v4 08/17] af_vsock: update comments for stream sockets Arseny Krasnov
2021-02-11 13:19   ` Stefano Garzarella
2021-02-11 13:19     ` Stefano Garzarella
2021-02-07 15:16 ` [RFC PATCH v4 09/17] virtio/vsock: dequeue callback for SOCK_SEQPACKET Arseny Krasnov
2021-02-11 13:54   ` Stefano Garzarella
2021-02-11 13:54     ` Stefano Garzarella
2021-02-11 14:03     ` Stefano Garzarella
2021-02-11 14:03       ` Stefano Garzarella
2021-02-07 15:17 ` [RFC PATCH v4 10/17] virtio/vsock: fetch length for SEQPACKET record Arseny Krasnov
2021-02-11 13:58   ` Stefano Garzarella
2021-02-11 13:58     ` Stefano Garzarella
2021-02-07 15:17 ` [RFC PATCH v4 11/17] virtio/vsock: add SEQPACKET receive logic Arseny Krasnov
2021-02-07 15:17 ` [RFC PATCH v4 12/17] virtio/vsock: rest of SOCK_SEQPACKET support Arseny Krasnov
2021-02-09  4:34   ` kernel test robot
2021-02-11 11:00   ` Arseny Krasnov
2021-02-11 14:29   ` Stefano Garzarella
2021-02-11 14:29     ` Stefano Garzarella
2021-02-07 15:18 ` [RFC PATCH v4 13/17] virtio/vsock: setup SEQPACKET ops for transport Arseny Krasnov
2021-02-07 15:18 ` [RFC PATCH v4 14/17] vhost/vsock: " Arseny Krasnov
2021-02-07 15:18 ` [RFC PATCH v4 15/17] vsock_test: add SOCK_SEQPACKET tests Arseny Krasnov
2021-02-07 15:18 ` [RFC PATCH v4 16/17] loopback/vsock: setup SEQPACKET ops for transport Arseny Krasnov
2021-02-11 14:31   ` Stefano Garzarella
2021-02-11 14:31     ` Stefano Garzarella
2021-02-07 15:19 ` [RFC PATCH v4 17/17] virtio/vsock: simplify credit update function API Arseny Krasnov
2021-02-11 14:39   ` Stefano Garzarella
2021-02-11 14:39     ` Stefano Garzarella
2021-02-07 16:20 ` [RFC PATCH v4 00/17] virtio/vsock: introduce SOCK_SEQPACKET support Michael S. Tsirkin
2021-02-07 16:20   ` Michael S. Tsirkin
2021-02-08  6:32   ` Arseny Krasnov
2021-02-11 14:57     ` Stefano Garzarella
2021-02-11 14:57       ` Stefano Garzarella
2021-02-12  6:11       ` Arseny Krasnov
2021-02-12  8:07         ` Stefano Garzarella
2021-02-12  8:07           ` Stefano Garzarella

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=20210211113753.o4zco3yromuxpvo2@steredhat \
    --to=sgarzare@redhat.com \
    --cc=andraprs@amazon.com \
    --cc=arseny.krasnov@kaspersky.com \
    --cc=colin.king@canonical.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=jeffv@google.com \
    --cc=jhansen@vmware.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oxffffaa@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=stsp2@yandex.ru \
    --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
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.