Message ID | 63445f2f-a0bb-153c-0e15-74a09ea26dc1@sberdevices.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp842923wrt; Sun, 19 Mar 2023 12:20:02 -0700 (PDT) X-Google-Smtp-Source: AK7set/RpDeKpI7WbwNSlEXyXTOYbH/SkNK69wR7d+aVJ2IpEIGexZxcjBNvg7rNzYrzAFrh6hVt X-Received: by 2002:a05:6a20:4ca0:b0:ce:2fb4:5fc4 with SMTP id fq32-20020a056a204ca000b000ce2fb45fc4mr14782046pzb.38.1679253602337; Sun, 19 Mar 2023 12:20:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679253602; cv=none; d=google.com; s=arc-20160816; b=aauyOiIeZVVp9Gzs98L4SUgzlHXRoQYq74b1XFKjStUJ1gbf33dWxNL/0MWu8o6YXU cwj/Oo8QlcJSmm4HFc2BZqmvzDcnK1EobvtsFsOmdGbqsFhSWkaD9oIEqdBXuqu4IcJH zqao7r2I7zi/RxsgV1JXVZM1Hpkrjq5o2t6yoxFYx0vV9xUnQ+3uM8ZBp5RrTU+ZCf0b gWb2WdCbqSYo3VaRJd1W+/Lvv2foHD4tAPYnvIbBs11gZcYVdz5syIpxIG+Wn4UDsP+m pKwtzKLG7LH3mCAf3eZPB4UoVg9xsTacqG47Y3cJJyn/IT84VC0tKL1P7e1J8VbP9FkD PCyQ== 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=4xeEPECpVnpzfQf1fesctV2AnA8LeKYtLCBEiuPhocg=; b=ofDqusTZkqTDIXkdmc4BwBod7+psJbWtFYaNalv6rIOFSdVLRLsEhpSSEWB0D0awx/ wRS8N7BzsqNEcrrExS/mmAXJ10yaNmcnrdnSOcH1t15Mb5qhmwFmN7gJ08O4TTuv2lpR DW77ZDSh2vMDG9Kdo08riRd2AVs6G6pSC/acn31p1vD3kg/2Oc8UY0gFCd2mzih/V+wt 7clO7/wgQU6ORsylZOARwvr7MWQUr3TMmbBoNuIyp5ZqHrB/JVu3GpUmjUcLchdu7Vxj qETJ5Ot2b4JwyMQZ88o6+TUpS+Dxtk2pbhMU2R7yKLlU5jUTiKIcae8z1zEZAAEAZFxw 34ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=akgHfvv8; 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 e11-20020a056a001a8b00b005a8bc2293c3si8453090pfv.263.2023.03.19.12.19.48; Sun, 19 Mar 2023 12:20:02 -0700 (PDT) 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=akgHfvv8; 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 S229877AbjCSSyf (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Sun, 19 Mar 2023 14:54:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229460AbjCSSyd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 19 Mar 2023 14:54:33 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 837FB196BE; Sun, 19 Mar 2023 11:54:32 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id D9CD05FD0B; Sun, 19 Mar 2023 21:54:30 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1679252070; bh=4xeEPECpVnpzfQf1fesctV2AnA8LeKYtLCBEiuPhocg=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=akgHfvv8AkVLHgeCDpICG7WM0q3/HjV+IbSmam+sMzpXSE0xxLodG4Y1ZxKLOWZA2 PBhBsJbTchNoIJfSBv45e0YwBoSNjYbrFoM+A9dw5y+dYgSHXOksoyTsSlmgJRhq0t hDPPb27+rrFfkVMqQ52mBFjK/RQ0qo5VBnLqIoU+6FWkJ2aRGddlfQrpqchr895ZVi Kr/Bx5/gMQx9dvMfF+u0SAXCqg7RNrJdxpUrpMuBBfg/LXFCJeGxiHMTPMLvU5FHs4 hRtNG3VjTcbNPqfu6ZTUjjwE8iFGWChJLo6v1Q78dlD8X1qrkniM95ca7qKB9NgV9S AZl93kgvL5/zw== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Sun, 19 Mar 2023 21:54:30 +0300 (MSK) Message-ID: <63445f2f-a0bb-153c-0e15-74a09ea26dc1@sberdevices.ru> Date: Sun, 19 Mar 2023 21:51:06 +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: <e141e6f1-00ae-232c-b840-b146bdb10e99@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 v1 1/3] virtio/vsock: fix header length on skb merging Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH02.sberdevices.ru (172.16.1.5) 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/19 16:43:00 #20974059 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?1760825025658304690?= X-GMAIL-MSGID: =?utf-8?q?1760825025658304690?= |
Series |
fix header length on skb merging
|
|
Commit Message
Arseniy Krasnov
March 19, 2023, 6:51 p.m. UTC
This fixes header length calculation of skbuff during data appending to
it. When such skbuff is processed in dequeue callbacks, e.g. 'skb_pull()'
is called on it, 'skb->len' is dynamic value, so it is impossible to use
it in header, because value from header must be permanent for valid
credit calculation ('rx_bytes'/'fwd_cnt').
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
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 19, 2023 at 09:51:06PM +0300, Arseniy Krasnov wrote: >This fixes header length calculation of skbuff during data appending to >it. When such skbuff is processed in dequeue callbacks, e.g. 'skb_pull()' >is called on it, 'skb->len' is dynamic value, so it is impossible to use >it in header, because value from header must be permanent for valid >credit calculation ('rx_bytes'/'fwd_cnt'). > >Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") I don't understand how this commit introduced this problem, can you explain it better? Is it related more to the credit than to the size in the header itself? Anyway, the patch LGTM, but we should explain better the issue. Thanks, Stefano >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 6d15cd4d090a..3c75986e16c2 100644 >--- a/net/vmw_vsock/virtio_transport_common.c >+++ b/net/vmw_vsock/virtio_transport_common.c >@@ -1091,7 +1091,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, > memcpy(skb_put(last_skb, skb->len), skb->data, skb->len); > free_pkt = true; > last_hdr->flags |= hdr->flags; >- last_hdr->len = cpu_to_le32(last_skb->len); >+ le32_add_cpu(&last_hdr->len, len); > goto out; > } > } >-- >2.25.1 >
On 20.03.2023 17:57, Stefano Garzarella wrote: > On Sun, Mar 19, 2023 at 09:51:06PM +0300, Arseniy Krasnov wrote: >> This fixes header length calculation of skbuff during data appending to >> it. When such skbuff is processed in dequeue callbacks, e.g. 'skb_pull()' >> is called on it, 'skb->len' is dynamic value, so it is impossible to use >> it in header, because value from header must be permanent for valid >> credit calculation ('rx_bytes'/'fwd_cnt'). >> >> Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") > > I don't understand how this commit introduced this problem, can you > explain it better? Sorry, seems i said it wrong a little bit. Before 0777, implementation was buggy, but exactly this problem was not actual - it didn't triggered somehow. I checked it with reproducer from this patch. But in 0777 as value from header was used to 'rx_bytes' calculation, bug become actual. Yes, may be it is not "Fixes:" for 0777, but critical addition. I'm not sure. > > Is it related more to the credit than to the size in the header itself? > It is related to size in header more. > Anyway, the patch LGTM, but we should explain better the issue. > Ok, I'll write it more clear in the commit message. Thanks, Arseniy > Thanks, > Stefano > >> 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 6d15cd4d090a..3c75986e16c2 100644 >> --- a/net/vmw_vsock/virtio_transport_common.c >> +++ b/net/vmw_vsock/virtio_transport_common.c >> @@ -1091,7 +1091,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, >> memcpy(skb_put(last_skb, skb->len), skb->data, skb->len); >> free_pkt = true; >> last_hdr->flags |= hdr->flags; >> - last_hdr->len = cpu_to_le32(last_skb->len); >> + le32_add_cpu(&last_hdr->len, len); >> goto out; >> } >> } >> -- >> 2.25.1 >> >
On Mon, Mar 20, 2023 at 09:10:13PM +0300, Arseniy Krasnov wrote: > > >On 20.03.2023 17:57, Stefano Garzarella wrote: >> On Sun, Mar 19, 2023 at 09:51:06PM +0300, Arseniy Krasnov wrote: >>> This fixes header length calculation of skbuff during data appending to >>> it. When such skbuff is processed in dequeue callbacks, e.g. 'skb_pull()' >>> is called on it, 'skb->len' is dynamic value, so it is impossible to use >>> it in header, because value from header must be permanent for valid >>> credit calculation ('rx_bytes'/'fwd_cnt'). >>> >>> Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit") >> >> I don't understand how this commit introduced this problem, can you >> explain it better? >Sorry, seems i said it wrong a little bit. Before 0777, implementation was buggy, but >exactly this problem was not actual - it didn't triggered somehow. I checked it with >reproducer from this patch. But in 0777 as value from header was used to 'rx_bytes' >calculation, bug become actual. Yes, may be it is not "Fixes:" for 0777, but critical >addition. I'm not sure. >> >> Is it related more to the credit than to the size in the header itself? >> >It is related to size in header more. >> Anyway, the patch LGTM, but we should explain better the issue. >> > >Ok, I'll write it more clear in the commit message. Okay, if 077706165717 triggered the problem, even if it was there from before, then IMHO it is okay to use that commit in Fixes. Please, explain it better in the message, so it's clear for everyone ;-) Thanks, Stefano
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index 6d15cd4d090a..3c75986e16c2 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1091,7 +1091,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk, memcpy(skb_put(last_skb, skb->len), skb->data, skb->len); free_pkt = true; last_hdr->flags |= hdr->flags; - last_hdr->len = cpu_to_le32(last_skb->len); + le32_add_cpu(&last_hdr->len, len); goto out; } }