Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2079924pxb; Thu, 11 Feb 2021 03:58:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJwGgaSXSkhDT4Dc7BhFhu9jLsiYu2DZbkEq/UiyQ0SJMpBoeRytxZJfNVyOIhWg0sFzt4XH X-Received: by 2002:a05:6402:31af:: with SMTP id dj15mr7939108edb.59.1613044738734; Thu, 11 Feb 2021 03:58:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613044738; cv=none; d=google.com; s=arc-20160816; b=pNOw+FJXzh7y9564dieJxlGEXLV+esL/IGpcT5ROgidXEyEJp9HYsuPXWSlgd2/fa1 iO7kh5uBdaig3UQasgjCMuH/262+gbIb8B5cQJhTpmwOG50iGETO84I2FZWe/R7B/k/z UyXi6g+OIK7d+0MgHhRI+lSj1CU9d9vPb+GF6C0/qYbUGHYfJaLi3RsuhGjPCy+Vv9Ho yAR9YHY5f+xbS3yiICHWUdqjvpuyvpMDhcIfwJ83aIApVKn/CQuQv4tOPH+AHjzNt+Lr ajiO97fAQjxsXqidWfjvQz4VmYH0dULvPhTLmDQd9dSwqB1dlevOtpbNrFTJ1kurU31A mSqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=jBJpn4LbluSU72a0eU+ANLaBQa/dsUCCbpTQvGN+K1w=; b=h8IazxHMr66JVn7TTxqKvcTDp/xD8RR3hWbiLjMOjGCmMHtMk7hrQ1lXyhM9OXito3 /2Dt7GKtogtB2sbgCNazztLCRo1QKPmOa44gTHOg61hsBf3vP4PsePP4XDtpfgJKqEbb P821keT7RXy01N5U9aBdeJ6YJfdGZJW9n1gnREuAl2g3JEM4hrIvz0kfGTYI0FqyPYaw TxonJimuNxjOGC4qUgVzS1Juwv30v6cxGpwBZG/bJwFgqjLSG8uu4S5M7SdoULYEp00T oQq9vwhEXoQD6ROEN0nNzD2XZSMYE3ckKbNQrJG0+17DBRiwExLWvOfpRxyv7P2Wme30 8YHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UL+FuWYp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e6si1125839ejs.366.2021.02.11.03.58.34; Thu, 11 Feb 2021 03:58:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UL+FuWYp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230299AbhBKL54 (ORCPT + 99 others); Thu, 11 Feb 2021 06:57:56 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:34276 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230328AbhBKLjb (ORCPT ); Thu, 11 Feb 2021 06:39:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613043479; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jBJpn4LbluSU72a0eU+ANLaBQa/dsUCCbpTQvGN+K1w=; b=UL+FuWYpqI8fgpgnsbr8CvDSg/Rbsy5iHR8kmWYvNHzf2QmxIYvi/k7JCHHPzfFrdfbleG kUBZQ/GnBb8kYy2XB9uB+zSllAXO0jRisGuz8A3O0uVEhy198+cHyAsBC80GQ+r2ZtvkzT OH1AZOqRhCmCxEu9QD07tI1n8fEkH4I= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-562-EoMickD6PHCgFWrT25nI4w-1; Thu, 11 Feb 2021 06:37:57 -0500 X-MC-Unique: EoMickD6PHCgFWrT25nI4w-1 Received: by mail-ed1-f69.google.com with SMTP id f21so4427845edx.10 for ; Thu, 11 Feb 2021 03:37:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jBJpn4LbluSU72a0eU+ANLaBQa/dsUCCbpTQvGN+K1w=; b=oaqZHpQaJbI1hbNhXlv0uq0TyW+wbXVhpY7vWstbJ2syvs2uc4aFfpkj2DDdu7v9lR QKlnh3k2qb+1QAC8j/OokR37RrnMmPS71vrZeuBFtAUW4xCGAZYClRCrBJ8hfHsD0tQM 9RQp6GH7zsA5uLhfWNRUjmYRZxIaNUsUmtO7542t6mvx+h1KnZUQJ8Oaf8UZBDoMFxJL 7gEXPvNsZM+736CTMPyPe0UUWxWEzPguhDchyVSuD6n9DjTy2SHLfePFnMYzOHZzxJet d8XbaFYYo4OnI/GtgaSe9irP+xwaWAZ9cxEW2YKCSOBsf4MEcavxkIv6VFe1mTpg2CXT ET7g== X-Gm-Message-State: AOAM531OYOLXmMyn5QLnkNtumZusvnjHmBVY9Jj8uh3HXxtxfYlQ3pxI i8lDtrv7zkQ+0eAB0OY5AlpE1sm+Os4HPQIF9b7RF3oZo76o+72ChoUsY6mtb5XDJ4Hlp+L9N6x 3iBLU/UbJxkZaggNSfie8x36D X-Received: by 2002:a17:906:37c1:: with SMTP id o1mr7920799ejc.488.1613043476412; Thu, 11 Feb 2021 03:37:56 -0800 (PST) X-Received: by 2002:a17:906:37c1:: with SMTP id o1mr7920773ejc.488.1613043476196; Thu, 11 Feb 2021 03:37:56 -0800 (PST) Received: from steredhat (host-79-34-249-199.business.telecomitalia.it. [79.34.249.199]) by smtp.gmail.com with ESMTPSA id m7sm3982087ejk.52.2021.02.11.03.37.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Feb 2021 03:37:55 -0800 (PST) Date: Thu, 11 Feb 2021 12:37:53 +0100 From: Stefano Garzarella To: Arseny Krasnov Cc: Stefan Hajnoczi , "Michael S. Tsirkin" , Jason Wang , "David S. Miller" , Jakub Kicinski , Jorgen Hansen , Colin Ian King , Andra Paraschiv , Jeff Vander Stoep , 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 Message-ID: <20210211113753.o4zco3yromuxpvo2@steredhat> References: <20210207151259.803917-1-arseny.krasnov@kaspersky.com> <20210207151508.804615-1-arseny.krasnov@kaspersky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20210207151508.804615-1-arseny.krasnov@kaspersky.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >--- > 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