Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp333789pxy; Wed, 21 Apr 2021 04:18:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5PANForyj4W1l61ENe985cmkwnyZ0Z6ZlXSfnLAi9NyIgApT4O86lcbDdjqufb0/asuB7 X-Received: by 2002:a63:4d8:: with SMTP id 207mr18091673pge.261.1619003925114; Wed, 21 Apr 2021 04:18:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619003925; cv=none; d=google.com; s=arc-20160816; b=k3rlA0WnbuH9PJrP6BNcH5es0dd90QWVt0YQ60C1NdHPRyAcNlGEWEYrVJ1jNNe6sR 5X6YhrtShHVv72Wdx55cSK78duwN5b5rIlNmC+Mi3H3ObbWyIrm/1sE3NqOYjy+teyBV FNYKUaXt9hx3N3gvK0L6sJ0kqxo1BHc3JXAUwIfbn/tBJahpbM2fTBjgcJjsNporC/14 q8z9ySCwflz0+uXiMzKaVFL92X+u2n6Xu9FVTM14UKS42nkQGtKuiybG9Hft+XcBQYyb 7mG99kVa+e1Be34x/qi1NnCn0X5L6hi9YamBwU+EaaUQ7q6amhj+fvrhOlhR6DYxHkcz tArA== 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=SEt58VbFvs2xemicT0zBRkhdh8N6/jqkICXkVkT9euM=; b=MukOEo98XiodTfc7tYEf1eGVmRsZW7/XrjF6BvOP4e+2IFck1xiO/yCRrd7wabzi0y xhts1BBlEIkHZsAKVD6eS0WEw5vRkUX+yaIaNuVpX0WPVeI5xMzQNgQxWcvaD4m5cbSe dtuPbv6lDBSNC6BXLpJzOUVYRLk1KywkfUexQG72YflBoRrNgQf/WGgsQEBg9h7T/Ziz lng0goFpysNAzWreojF9+e1Wl/DGek6APwwfk8byrNgsWvxCA6grmddKohc/5VZ08dzq D0pJ22ACU1tziq4AOKBeF0K9RI8cXKKCU+OTq2mDS2jQDfYXeCUZup7D908MuONzvCP4 69rQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cZm+KwkL; 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 c18si2115304plg.336.2021.04.21.04.18.33; Wed, 21 Apr 2021 04:18:45 -0700 (PDT) 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=cZm+KwkL; 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 S237663AbhDUI5Z (ORCPT + 99 others); Wed, 21 Apr 2021 04:57:25 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:29770 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235497AbhDUI5Y (ORCPT ); Wed, 21 Apr 2021 04:57:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618995411; 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=SEt58VbFvs2xemicT0zBRkhdh8N6/jqkICXkVkT9euM=; b=cZm+KwkLdm0d34/aLSayBy99G+aWAf80SXiafy1XhW52uIk/VN7+8IPBN+lumBns+TY+2H 252mrKhcK5qQU2XAqXyUUQQ5/CD+94da5ZE4LZ1Bvz+GmLOuShBWbHlS8BtahU5AOJprHn DHXURcvzF8PVif3tY/2MIO9PrANB5Xg= 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-375-jUhFvTwpN9WfKZODUXxfZg-1; Wed, 21 Apr 2021 04:56:49 -0400 X-MC-Unique: jUhFvTwpN9WfKZODUXxfZg-1 Received: by mail-ed1-f69.google.com with SMTP id l7-20020aa7c3070000b029038502ffe9f2so8875883edq.16 for ; Wed, 21 Apr 2021 01:56:49 -0700 (PDT) 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=SEt58VbFvs2xemicT0zBRkhdh8N6/jqkICXkVkT9euM=; b=X4UmX0Gj3lr1269eOhzDxPmEcCaU1+M6PechdNUF+On4YRyOsDeYtUXQpx21LFo6/A /kQW7ZoktJSSxG4wvU5Mk4S/uM+wx5EbIpep1ooVm07p0lgbvaQV1bdWiTvvZOg1vZpi eYSevc6roQzbzgD+Q4km8TiqUqD44kNHn6zLfyx/Hf1D5izk0bpHH1rJzBCX5KkkIu/T VyRlw+phUP7ysERRUMciFgp7zK8Hwwbt46gg5c621g7YJXB/n3VtlXV+XnsIlJqAYPa3 AKUaOEZWPHK2RGqxGdIPHqz/MYPaYWcgnrnGIEWKEwo6PfmgYENBYhexERSgV6BmhEUI ZKXg== X-Gm-Message-State: AOAM533d6i7TnVIFSzpwzEoY9jfdBe4Z/h8uZzuKt+OV21knGB0wJ14s aaNZ4jeXuW2EBAyQZi/nArtMuzV5KT69DFqb7e3BK0s52d7JMtOw3TxzvV2HHHRaagqps0kfaoG O7zpZGeHmrOhC0It+t6i2kqJq X-Received: by 2002:a05:6402:3079:: with SMTP id bs25mr37112005edb.369.1618995408386; Wed, 21 Apr 2021 01:56:48 -0700 (PDT) X-Received: by 2002:a05:6402:3079:: with SMTP id bs25mr37111975edb.369.1618995408182; Wed, 21 Apr 2021 01:56:48 -0700 (PDT) Received: from steredhat (host-79-34-249-199.business.telecomitalia.it. [79.34.249.199]) by smtp.gmail.com with ESMTPSA id w1sm2452811edt.89.2021.04.21.01.56.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Apr 2021 01:56:47 -0700 (PDT) Date: Wed, 21 Apr 2021 10:56:45 +0200 From: Stefano Garzarella To: Arseny Krasnov Cc: Stefan Hajnoczi , "Michael S. Tsirkin" , Jason Wang , "David S. Miller" , Jakub Kicinski , Jorgen Hansen , Andra Paraschiv , Colin Ian King , Norbert Slusarek , Jeff Vander Stoep , Alexander Popov , kvm , Linux Virtualization , netdev , kernel list , stsp , Krasnov Arseniy Subject: Re: [RFC PATCH v8 11/19] virtio/vsock: dequeue callback for SOCK_SEQPACKET Message-ID: References: <20210413123954.3396314-1-arseny.krasnov@kaspersky.com> <20210413124443.3403382-1-arseny.krasnov@kaspersky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210413124443.3403382-1-arseny.krasnov@kaspersky.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 13, 2021 at 03:44:40PM +0300, Arseny Krasnov wrote: >This adds transport callback and it's logic for SEQPACKET dequeue. >Callback fetches RW packets from rx queue of socket until whole record >is copied(if user's buffer is full, user is not woken up). This is done >to not stall sender, because if we wake up user and it leaves syscall, >nobody will send credit update for rest of record, and sender will wait >for next enter of read syscall at receiver's side. So if user buffer is >full, we just send credit update and drop data. > >Signed-off-by: Arseny Krasnov >--- >v7 -> v8: > - Things like SEQ_BEGIN, SEQ_END, 'msg_len' and 'msg_id' now removed. > This callback fetches and copies RW packets to user's buffer, until > last packet of message found(this packet is marked in 'flags' field > of header). > > include/linux/virtio_vsock.h | 5 ++ > net/vmw_vsock/virtio_transport_common.c | 73 +++++++++++++++++++++++++ > 2 files changed, 78 insertions(+) > >diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h >index dc636b727179..02acf6e9ae04 100644 >--- a/include/linux/virtio_vsock.h >+++ b/include/linux/virtio_vsock.h >@@ -80,6 +80,11 @@ virtio_transport_dgram_dequeue(struct vsock_sock *vsk, > struct msghdr *msg, > size_t len, int flags); > >+ssize_t >+virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk, >+ struct msghdr *msg, >+ int flags, >+ bool *msg_ready); > s64 virtio_transport_stream_has_data(struct vsock_sock *vsk); > s64 virtio_transport_stream_has_space(struct vsock_sock *vsk); > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >index 833104b71a1c..8492b8bd5df5 100644 >--- a/net/vmw_vsock/virtio_transport_common.c >+++ b/net/vmw_vsock/virtio_transport_common.c >@@ -393,6 +393,67 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, > return err; > } > >+static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk, >+ struct msghdr *msg, >+ int flags, >+ bool *msg_ready) >+{ >+ struct virtio_vsock_sock *vvs = vsk->trans; >+ struct virtio_vsock_pkt *pkt; >+ int err = 0; >+ size_t user_buf_len = msg->msg_iter.count; >+ >+ *msg_ready = false; >+ spin_lock_bh(&vvs->rx_lock); >+ >+ while (!*msg_ready && !list_empty(&vvs->rx_queue) && err >= 0) { >+ pkt = list_first_entry(&vvs->rx_queue, struct virtio_vsock_pkt, list); >+ >+ if (le16_to_cpu(pkt->hdr.op) == VIRTIO_VSOCK_OP_RW) { Is this check still necessary, should they all be RW? >+ size_t bytes_to_copy; >+ size_t pkt_len; >+ >+ pkt_len = (size_t)le32_to_cpu(pkt->hdr.len); >+ bytes_to_copy = min(user_buf_len, pkt_len); >+ If bytes_to_copy == 0, we can avoid the next steps (release the lock try to copy 0 bytes, reacquire the lock) >+ /* sk_lock is held by caller so no one else can dequeue. >+ * Unlock rx_lock since memcpy_to_msg() may sleep. >+ */ >+ spin_unlock_bh(&vvs->rx_lock); >+ >+ if (memcpy_to_msg(msg, pkt->buf, bytes_to_copy)) { >+ err = -EINVAL; Here we should reacquire the lock or prevent it from being released out of cycle. >+ break; >+ } >+ >+ spin_lock_bh(&vvs->rx_lock); >+ As mentioned before, I think we could move this part into the core and here always return the real dimension. >+ /* If user sets 'MSG_TRUNC' we return real >length >+ * of message. >+ */ >+ if (flags & MSG_TRUNC) >+ err += pkt_len; >+ else >+ err += bytes_to_copy; >+ >+ user_buf_len -= bytes_to_copy; >+ >+ if (pkt->hdr.flags & VIRTIO_VSOCK_SEQ_EOR) ^ We should use le32_to_cpu() to read the flags. >+ *msg_ready = true; >+ } >+ >+ virtio_transport_dec_rx_pkt(vvs, pkt); >+ list_del(&pkt->list); >+ virtio_transport_free_pkt(pkt); >+ } >+ >+ spin_unlock_bh(&vvs->rx_lock); >+ >+ virtio_transport_send_credit_update(vsk); >+ >+ return err; >+} >+ > ssize_t > virtio_transport_stream_dequeue(struct vsock_sock *vsk, > struct msghdr *msg, >@@ -405,6 +466,18 @@ virtio_transport_stream_dequeue(struct vsock_sock *vsk, > } > EXPORT_SYMBOL_GPL(virtio_transport_stream_dequeue); > >+ssize_t >+virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk, >+ struct msghdr *msg, >+ int flags, bool *msg_ready) >+{ >+ if (flags & MSG_PEEK) >+ return -EOPNOTSUPP; >+ >+ return virtio_transport_seqpacket_do_dequeue(vsk, msg, flags, >msg_ready); >+} >+EXPORT_SYMBOL_GPL(virtio_transport_seqpacket_dequeue); >+ > int > virtio_transport_dgram_dequeue(struct vsock_sock *vsk, > struct msghdr *msg, >-- >2.25.1 >