virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
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, Norbert Slusarek <nslusarek@gmx.net>,
	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>,
	Alexander Popov <alex.popov@linux.com>
Subject: Re: [RFC PATCH v7 03/22] af_vsock: separate receive data loop
Date: Thu, 25 Mar 2021 10:06:31 +0100	[thread overview]
Message-ID: <20210325090631.4o5lc2kgyb4uzslh@steredhat> (raw)
In-Reply-To: <20210323130939.2459901-1-arseny.krasnov@kaspersky.com>

On Tue, Mar 23, 2021 at 04:09:36PM +0300, Arseny Krasnov wrote:
>Move STREAM specific data receive logic to '__vsock_stream_recvmsg()'
>dedicated function, while checks, that will be same for both STREAM
>and SEQPACKET sockets, stays in 'vsock_connectible_recvmsg()' shared
>functions.
>
>Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>
>---
> net/vmw_vsock/af_vsock.c | 116 ++++++++++++++++++++++-----------------
> 1 file changed, 67 insertions(+), 49 deletions(-)

I had already reviewed this in v5 and in v6 you reported the R-b tag.

Usually the tag gets removed if you make changes to the patch or the 
reviewer is no longer happy. But this doesn't seem to be the case.

So please keep the tags between versions :-)


Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>

>
>diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
>index 421c0303b26f..0bc661e54262 100644
>--- a/net/vmw_vsock/af_vsock.c
>+++ b/net/vmw_vsock/af_vsock.c
>@@ -1895,65 +1895,22 @@ static int vsock_wait_data(struct sock *sk, struct wait_queue_entry *wait,
> 	return data;
> }
>
>-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
>@@ -2012,6 +1969,67 @@ vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
> 	if (copied > 0)
> 		err = copied;
>
>+out:
>+	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;
>-- 
>2.25.1
>

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

       reply	other threads:[~2021-03-25  9:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210323130716.2459195-1-arseny.krasnov@kaspersky.com>
     [not found] ` <20210323130939.2459901-1-arseny.krasnov@kaspersky.com>
2021-03-25  9:06   ` Stefano Garzarella [this message]
     [not found] ` <20210323131006.2460058-1-arseny.krasnov@kaspersky.com>
2021-03-25  9:34   ` [RFC PATCH v7 04/22] af_vsock: implement SEQPACKET receive loop Stefano Garzarella
     [not found] ` <20210323131026.2460194-1-arseny.krasnov@kaspersky.com>
2021-03-25  9:37   ` [RFC PATCH v7 05/22] af_vsock: separate wait space loop Stefano Garzarella
     [not found] ` <20210323131045.2460319-1-arseny.krasnov@kaspersky.com>
2021-03-25  9:42   ` [RFC PATCH v7 06/22] af_vsock: implement send logic for SEQPACKET Stefano Garzarella
     [not found] ` <20210323131244.2461050-1-arseny.krasnov@kaspersky.com>
2021-03-25  9:56   ` [RFC PATCH v7 11/22] virtio/vsock: dequeue callback for SOCK_SEQPACKET Stefano Garzarella
     [not found] ` <20210323131258.2461163-1-arseny.krasnov@kaspersky.com>
2021-03-25 10:08   ` [RFC PATCH v7 12/22] virtio/vsock: fetch length for SEQPACKET record Stefano Garzarella
     [not found] ` <20210323131316.2461284-1-arseny.krasnov@kaspersky.com>
2021-03-25 10:09   ` [RFC PATCH v7 13/22] virtio/vsock: add SEQPACKET receive logic Stefano Garzarella
     [not found] ` <20210323131332.2461409-1-arseny.krasnov@kaspersky.com>
2021-03-25 10:18   ` [RFC PATCH v7 14/22] virtio/vsock: rest of SOCK_SEQPACKET support Stefano Garzarella
     [not found] ` <20210323131352.2461534-1-arseny.krasnov@kaspersky.com>
2021-03-25 10:26   ` [RFC PATCH v7 15/22] virtio/vsock: SEQPACKET support feature bit Stefano Garzarella
     [not found] ` <20210323131406.2461651-1-arseny.krasnov@kaspersky.com>
2021-03-25 10:39   ` [RFC PATCH v7 16/22] virtio/vsock: setup SEQPACKET ops for transport Stefano Garzarella
     [not found] ` <20210323131421.2461760-1-arseny.krasnov@kaspersky.com>
2021-03-25 10:42   ` [RFC PATCH v7 17/22] vhost/vsock: " Stefano Garzarella
     [not found] ` <20210323131436.2461881-1-arseny.krasnov@kaspersky.com>
2021-03-25 10:48   ` [RFC PATCH v7 18/22] vsock/loopback: " Stefano Garzarella
2021-03-25 10:52 ` [RFC PATCH v7 00/22] virtio/vsock: introduce SOCK_SEQPACKET support 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=20210325090631.4o5lc2kgyb4uzslh@steredhat \
    --to=sgarzare@redhat.com \
    --cc=alex.popov@linux.com \
    --cc=andraprs@amazon.com \
    --cc=arseny.krasnov@kaspersky.com \
    --cc=colin.king@canonical.com \
    --cc=davem@davemloft.net \
    --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=nslusarek@gmx.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).