Message ID | 4a3f3978-1093-4c0a-663f-28d77eeb0806@sberdevices.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1513963wrd; Sun, 5 Mar 2023 12:12:07 -0800 (PST) X-Google-Smtp-Source: AK7set8AgvlZuT0nHJC4GOqAAbfVEv0wA1uLKN8QydF1uMA9ltjepbw9qEzbZruSERRhwzHQDfsx X-Received: by 2002:a17:907:1c0e:b0:8b1:78b6:4b3c with SMTP id nc14-20020a1709071c0e00b008b178b64b3cmr11236304ejc.73.1678047127158; Sun, 05 Mar 2023 12:12:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678047127; cv=none; d=google.com; s=arc-20160816; b=oTYo7k7soSLaHnRGuB0DP5tVRehAkbmrpM9ojP7hkrnFrsCztJ2UsTKyNxL9jj8jey QMg0+aCq9/rKAdwgsC8q2/1jZd6DvwjTyHQa0m3xy0Gr3TPKR7hhEoXUuHPYtVtFy0qQ 7K8GU6zWS4cWncSNbLJt4svvr6zFBrUti2p1y0Rowpr9lTFaW+1cAitUEzemVdRKK1PQ sPhia5KFY34FZFe4QCpPlWEM1wUBMzAk6S+pVfZK89c3DOmFzfWsJoowEpVe3qunoCf/ B20LZlSxJsxm1P9HfYORo58rQsj2X2fZ76twu6yeI5FdJvK//ch5Pwuo8cpQZ098anZ6 o5uQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:from:cc:to :in-reply-to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=OP9Q+D6ddKpeccLb8Rmg9aPK4JcBMYN/s1rz2P24TnQ=; b=LPyI3+AKfc98Mj6fCeVq4EaT7du5bM4fguvKI6p40UB24oYZgNRf9x3zmrBh2nqgyb 8MPOUScBpdhPGL27OcrI16BvE884B9Pbs3sp0eEceNhyjqk0hGUL3wQ/muhtKh4H/YOJ LwuVfwy/afPfGKMLtZBIFKWCdj6uxav6B+S6Ejd16SYH1vPZSjp2RK58SlyeBExzetyJ EWhJUzOPRJ1/Fecq+qVSZBIBjF7MimZTFdSaosn7M28eSGRqkQu9Ueo5ePOxl4gUedew 2PoNXotMIEwnciACXcJOpda1RnbA3MAzKOKVuqx9r3bvLbsVHb3SXen0x8OMMCK//RXV cRUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=pvRXfzfY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q21-20020a170906541500b008e86646e6bdsi8213989ejo.1008.2023.03.05.12.11.43; Sun, 05 Mar 2023 12:12:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=pvRXfzfY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229646AbjCEUJZ (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Sun, 5 Mar 2023 15:09:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229500AbjCEUJX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 5 Mar 2023 15:09:23 -0500 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 116FE6EBD; Sun, 5 Mar 2023 12:09:22 -0800 (PST) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 6D6655FD04; Sun, 5 Mar 2023 23:09:20 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1678046960; bh=OP9Q+D6ddKpeccLb8Rmg9aPK4JcBMYN/s1rz2P24TnQ=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=pvRXfzfYGzpc+pLpl2XVgBwgUqDIDKDVwBu61NuJw6pFIFzwQ4JMJ989jxq6qWvwN VoVc15b+2FrAtp9/WVnm7jC5rhl8b3mMuS5/oxY1tMM8+8Kh3AvIYBgMXWbq8HyIhA Cz+O6dfugq9AI4+y6liW4YAguudzQBIpmFbJ/LgjswJv9eu+yvJyQDium+NNcgat3y GIevkso0bdj7Rg1/FJIwjXB/GUoomtoYx4x7aTb+nAh71laGR11mgOdjmeja9G1AOL rFaKu+YfWjTXQyIcLocFUIEdke9//kdGTc70SQheIYP64wSLHaouTAOSm6YlcJCM9N i+iegLpyxz8pw== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Sun, 5 Mar 2023 23:09:19 +0300 (MSK) Message-ID: <4a3f3978-1093-4c0a-663f-28d77eeb0806@sberdevices.ru> Date: Sun, 5 Mar 2023 23:06:26 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-US In-Reply-To: <a7ab414b-5e41-c7b6-250b-e8401f335859@sberdevices.ru> To: Stefan Hajnoczi <stefanha@redhat.com>, Stefano Garzarella <sgarzare@redhat.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Bobby Eshleman <bobby.eshleman@bytedance.com> CC: <kvm@vger.kernel.org>, <virtualization@lists.linux-foundation.org>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <kernel@sberdevices.ru>, <oxffffaa@gmail.com>, <avkrasnov@sberdevices.ru> From: Arseniy Krasnov <avkrasnov@sberdevices.ru> Subject: [RFC PATCH v2 1/4] virtio/vsock: fix 'rx_bytes'/'fwd_cnt' calculation Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH01.sberdevices.ru (172.16.1.4) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/03/05 16:13:00 #20917262 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759559944561149924?= X-GMAIL-MSGID: =?utf-8?q?1759559944561149924?= |
Series |
virtio/vsock: fix credit update logic
|
|
Commit Message
Arseniy Krasnov
March 5, 2023, 8:06 p.m. UTC
Substraction of 'skb->len' is redundant here: 'skb_headroom()' is delta
between 'data' and 'head' pointers, e.g. it is number of bytes returned
to user (of course accounting size of header). 'skb->len' is number of
bytes rest in buffer.
Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
---
net/vmw_vsock/virtio_transport_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Sun, Mar 05, 2023 at 11:06:26PM +0300, Arseniy Krasnov wrote: >Substraction of 'skb->len' is redundant here: 'skb_headroom()' is delta >between 'data' and 'head' pointers, e.g. it is number of bytes returned >to user (of course accounting size of header). 'skb->len' is number of >bytes rest in buffer. > >Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") >Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >--- > net/vmw_vsock/virtio_transport_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >index a1581c77cf84..2e2a773df5c1 100644 >--- a/net/vmw_vsock/virtio_transport_common.c >+++ b/net/vmw_vsock/virtio_transport_common.c >@@ -255,7 +255,7 @@ static void virtio_transport_dec_rx_pkt(struct virtio_vsock_sock *vvs, > { > int len; > >- len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len; >+ len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr); IIUC virtio_transport_dec_rx_pkt() is always called after skb_pull(), so skb_headroom() is returning the amount of space we removed. Looking at the other patches in this series, I think maybe we should change virtio_transport_dec_rx_pkt() and virtio_transport_inc_rx_pkt() by passing the value to subtract or add directly. Since some times we don't remove the whole payload, so it would be better to call it with the value in hdr->len. I mean something like this (untested): index a1581c77cf84..9e69ae7a9a96 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -241,21 +241,18 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk, } static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs, - struct sk_buff *skb) + u32 len) { - if (vvs->rx_bytes + skb->len > vvs->buf_alloc) + if (vvs->rx_bytes + len > vvs->buf_alloc) return false; - vvs->rx_bytes += skb->len; + vvs->rx_bytes += len; return true; } static void virtio_transport_dec_rx_pkt(struct virtio_vsock_sock *vvs, - struct sk_buff *skb) + u32 len) { - int len; - - len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len; vvs->rx_bytes -= len; vvs->fwd_cnt += len; } @@ -388,7 +385,7 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, skb_pull(skb, bytes); if (skb->len == 0) { - virtio_transport_dec_rx_pkt(vvs, skb); + virtio_transport_dec_rx_pkt(vvs, bytes); consume_skb(skb); } else { __skb_queue_head(&vvs->rx_queue, skb); @@ -437,17 +434,17 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk, while (!msg_ready) { struct virtio_vsock_hdr *hdr; + size_t pkt_len; skb = __skb_dequeue(&vvs->rx_queue); if (!skb) break; hdr = virtio_vsock_hdr(skb); + pkt_len = (size_t)le32_to_cpu(hdr->len); if (dequeued_len >= 0) { - size_t pkt_len; size_t bytes_to_copy; - pkt_len = (size_t)le32_to_cpu(hdr->len); bytes_to_copy = min(user_buf_len, pkt_len); if (bytes_to_copy) { @@ -484,7 +481,7 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk, msg->msg_flags |= MSG_EOR; } - virtio_transport_dec_rx_pkt(vvs, skb); + virtio_transport_dec_rx_pkt(vvs, pkt_len); kfree_skb(skb); } @@ -1040,7 +1037,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, spin_lock_bh(&vvs->rx_lock); - can_enqueue = virtio_transport_inc_rx_pkt(vvs, skb); + can_enqueue = virtio_transport_inc_rx_pkt(vvs, len); if (!can_enqueue) { free_pkt = true; goto out; When we used vsock_pkt, we were passing the structure because the `len` field was immutable (and copied from the header), whereas with skb it can change and so we introduced these errors. What do you think? Thanks, Stefano
On 06.03.2023 14:57, Stefano Garzarella wrote: > On Sun, Mar 05, 2023 at 11:06:26PM +0300, Arseniy Krasnov wrote: >> Substraction of 'skb->len' is redundant here: 'skb_headroom()' is delta >> between 'data' and 'head' pointers, e.g. it is number of bytes returned >> to user (of course accounting size of header). 'skb->len' is number of >> bytes rest in buffer. >> >> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") >> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >> --- >> net/vmw_vsock/virtio_transport_common.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >> index a1581c77cf84..2e2a773df5c1 100644 >> --- a/net/vmw_vsock/virtio_transport_common.c >> +++ b/net/vmw_vsock/virtio_transport_common.c >> @@ -255,7 +255,7 @@ static void virtio_transport_dec_rx_pkt(struct virtio_vsock_sock *vvs, >> { >> int len; >> >> - len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len; >> + len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr); > > IIUC virtio_transport_dec_rx_pkt() is always called after skb_pull(), > so skb_headroom() is returning the amount of space we removed. > > Looking at the other patches in this series, I think maybe we should > change virtio_transport_dec_rx_pkt() and virtio_transport_inc_rx_pkt() > by passing the value to subtract or add directly. > Since some times we don't remove the whole payload, so it would be > better to call it with the value in hdr->len. > > I mean something like this (untested): > > index a1581c77cf84..9e69ae7a9a96 100644 > --- a/net/vmw_vsock/virtio_transport_common.c > +++ b/net/vmw_vsock/virtio_transport_common.c > @@ -241,21 +241,18 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk, > } > > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs, > - struct sk_buff *skb) > + u32 len) > { > - if (vvs->rx_bytes + skb->len > vvs->buf_alloc) > + if (vvs->rx_bytes + len > vvs->buf_alloc) > return false; > > - vvs->rx_bytes += skb->len; > + vvs->rx_bytes += len; > return true; > } > > static void virtio_transport_dec_rx_pkt(struct virtio_vsock_sock *vvs, > - struct sk_buff *skb) > + u32 len) > { > - int len; > - > - len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len; > vvs->rx_bytes -= len; > vvs->fwd_cnt += len; > } > @@ -388,7 +385,7 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, > skb_pull(skb, bytes); > > if (skb->len == 0) { > - virtio_transport_dec_rx_pkt(vvs, skb); > + virtio_transport_dec_rx_pkt(vvs, bytes); > consume_skb(skb); > } else { > __skb_queue_head(&vvs->rx_queue, skb); > @@ -437,17 +434,17 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk, > > while (!msg_ready) { > struct virtio_vsock_hdr *hdr; > + size_t pkt_len; > > skb = __skb_dequeue(&vvs->rx_queue); > if (!skb) > break; > hdr = virtio_vsock_hdr(skb); > + pkt_len = (size_t)le32_to_cpu(hdr->len); > > if (dequeued_len >= 0) { > - size_t pkt_len; > size_t bytes_to_copy; > > - pkt_len = (size_t)le32_to_cpu(hdr->len); > bytes_to_copy = min(user_buf_len, pkt_len); > > if (bytes_to_copy) { > @@ -484,7 +481,7 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk, > msg->msg_flags |= MSG_EOR; > } > > - virtio_transport_dec_rx_pkt(vvs, skb); > + virtio_transport_dec_rx_pkt(vvs, pkt_len); > kfree_skb(skb); > } > > @@ -1040,7 +1037,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, > > spin_lock_bh(&vvs->rx_lock); > > - can_enqueue = virtio_transport_inc_rx_pkt(vvs, skb); > + can_enqueue = virtio_transport_inc_rx_pkt(vvs, len); > if (!can_enqueue) { > free_pkt = true; > goto out; > > When we used vsock_pkt, we were passing the structure because the `len` > field was immutable (and copied from the header), whereas with skb it > can change and so we introduced these errors. > > What do you think? Yes, i think passing explicit integer value to 'virtio_transport_inc/dec_rx_pkt' is more clear solution. I had this variant, but thought that current will be smaller. Current version with skb argument forces to call 'skb_pull()' before each 'virtio_transport_dec_rx_pkt()' as 'rx_bytes'/'fwd_cnt' new value relies on skb parameters - otherwise 'rx_bytes' become invalid. 'skb_pull()' will be used only to update 'skb->len' which shows rest of the data. I'll do it in v3. Thanks, Arseniy > > Thanks, > Stefano >
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index a1581c77cf84..2e2a773df5c1 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -255,7 +255,7 @@ static void virtio_transport_dec_rx_pkt(struct virtio_vsock_sock *vvs, { int len; - len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len; + len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr); vvs->rx_bytes -= len; vvs->fwd_cnt += len; }