Message ID | ef98aad4-f86d-fe60-9a35-792363a78a68@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 v21csp1514663wrd; Sun, 5 Mar 2023 12:14:12 -0800 (PST) X-Google-Smtp-Source: AK7set+eKlJhm62EtAq69+7zi3GaSKpiI3SA3Ue7jKwbD0S1YRM7vZLkz7OiZpT3pOGnOdUPOGPm X-Received: by 2002:aa7:c242:0:b0:4ab:4c5e:b0ed with SMTP id y2-20020aa7c242000000b004ab4c5eb0edmr7221813edo.21.1678047252671; Sun, 05 Mar 2023 12:14:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678047252; cv=none; d=google.com; s=arc-20160816; b=yOKUO4Mj0fgogBl94RYfh6wFEnzljxL5CoWeNaF4D/PHHR93a5glYBB3N8SOZw2itP vhU+ewrChM2dH9G4703Mn+j5cgvIuflSnfEp+8BCB8wQPriTwWKmLigLj2ir+LK5w+Iq m8L0imQgqzzLi7BojKO6gd8sqWjmI1F4kOp6zCzaMXIFRgLGTFhdz5hmAdDrfYbRyN4U 1vU2ICeHSFbe6vPpIJWF/7PK6vIW/1AZPn07kLqBY4am4w2o9NkSF24XFmC6dU0uWVfU TGTWVBRiZWHzvJsUGhDCLmcknI682CX/3pG5KG222bNuDpLK7s8GEUYbAk9Lax91CBUv sLLQ== 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=L7Da6J5rFTLCyGxPPlCQpR06uIFFfMTCDUQ95Mc4yIg=; b=lTm3Rn7B6tEgh+OmTdt+a6M8CW40TXJoNaWXBrAr9kCVbDj5fUfTeW21v/4uaSzuRQ JbJeNv4vE2hDCixFfj6BLOw/CUPe66vYi1RkBW1LuwY1+23k6I5veeTQsEshTddAz5Yd Y/JuFpm4YScZN7NKLaMhmxRcL2pKHgJo1O34zEIHQHgSZ5VvQCLA3Fq7C1Plxaj7o69K RLh2UPsErXSvhddxJpi9WbPDC/n1py0hAkxL6B8ti8nd3Cr3nyveh7E1CNXTb94pFC9/ YIg0cU6mxJwU7ukmgjAf03oStp9gG0bO0md/3jN6i8UmCTvk0r5w7RSfs5wS8w1qLnYO DEAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=sAYdmP2F; 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 n16-20020aa7db50000000b004ce1d99975bsi3775105edt.93.2023.03.05.12.13.49; Sun, 05 Mar 2023 12:14:12 -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=sAYdmP2F; 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 S229729AbjCEULl (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Sun, 5 Mar 2023 15:11:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229688AbjCEULk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 5 Mar 2023 15:11:40 -0500 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDD0917CDD; Sun, 5 Mar 2023 12:11:33 -0800 (PST) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 0E01A5FD04; Sun, 5 Mar 2023 23:11:32 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1678047092; bh=L7Da6J5rFTLCyGxPPlCQpR06uIFFfMTCDUQ95Mc4yIg=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=sAYdmP2FkWe3wXhXTMZu6zuZLixtYz3kfbiRaUzkwIJKRmHsdp26jhM7OHQx/iSNd n0G8Xbk2uvUUruBpIw5WTl9Rjg3NZkSYLkZPo1Z3+gDbSLvqf8uiD1U61X1t7XYX8t EvPlzNk5v9YyfmmEQ/8WgRdy3AHYX10hkcPSdJF6Yq7pC/XxCLZpjtPziLcpuWMZnU m1+dSW8I+Cq8tMA/TpzhNBBC+At2IHavY9xQ/fpuofE2G/QoHX3K0KawRb3M4xIG1Y ErLqdyDkQ7uihZJyZVjJifcTWOWyvdWh3rA7gmL9kaf7RVt1fuE2YYjUMFiVHoNpGe JU65c1wBdgALA== 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:11:31 +0300 (MSK) Message-ID: <ef98aad4-f86d-fe60-9a35-792363a78a68@sberdevices.ru> Date: Sun, 5 Mar 2023 23:08:38 +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 3/4] virtio/vsock: free skb on data copy failure 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/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?1759560076042661942?= X-GMAIL-MSGID: =?utf-8?q?1759560076042661942?= |
Series |
virtio/vsock: fix credit update logic
|
|
Commit Message
Arseniy Krasnov
March 5, 2023, 8:08 p.m. UTC
This fixes two things in case when 'memcpy_to_msg()' fails:
1) Update credit parameters of the socket, like this skbuff was
copied to user successfully. This is needed because when skbuff was
received it's length was used to update 'rx_bytes', thus when we drop
skbuff here, we must account rest of it's data in 'rx_bytes'.
2) Free skbuff which was removed from socket's queue.
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 | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On Sun, Mar 05, 2023 at 11:08:38PM +0300, Arseniy Krasnov wrote: >This fixes two things in case when 'memcpy_to_msg()' fails: >1) Update credit parameters of the socket, like this skbuff was > copied to user successfully. This is needed because when skbuff was > received it's length was used to update 'rx_bytes', thus when we drop > skbuff here, we must account rest of it's data in 'rx_bytes'. >2) Free skbuff which was removed from socket's queue. > >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 | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >index 30b0539990ba..ffb1af4f2b52 100644 >--- a/net/vmw_vsock/virtio_transport_common.c >+++ b/net/vmw_vsock/virtio_transport_common.c >@@ -379,8 +379,12 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, > spin_unlock_bh(&vvs->rx_lock); > > err = memcpy_to_msg(msg, skb->data, bytes); >- if (err) >+ if (err) { >+ skb_pull(skb, skb->len); >+ virtio_transport_dec_rx_pkt(vvs, skb); >+ consume_skb(skb); I'm not sure it's the right thing to do, if we fail to copy the content into the user's buffer, I think we should queue it again. In fact, before commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff"), we used to remove the packet from the rx_queue, only if memcpy_to_msg() was successful. Maybe it is better to do as we did before and use skb_peek() at the beginning of the loop and __skb_unlink() when skb->len == 0. Thanks, Stefano > goto out; >+ } > > spin_lock_bh(&vvs->rx_lock); > >-- >2.25.1 >
On 06.03.2023 15:07, Stefano Garzarella wrote: > On Sun, Mar 05, 2023 at 11:08:38PM +0300, Arseniy Krasnov wrote: >> This fixes two things in case when 'memcpy_to_msg()' fails: >> 1) Update credit parameters of the socket, like this skbuff was >> copied to user successfully. This is needed because when skbuff was >> received it's length was used to update 'rx_bytes', thus when we drop >> skbuff here, we must account rest of it's data in 'rx_bytes'. >> 2) Free skbuff which was removed from socket's queue. >> >> 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 | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >> index 30b0539990ba..ffb1af4f2b52 100644 >> --- a/net/vmw_vsock/virtio_transport_common.c >> +++ b/net/vmw_vsock/virtio_transport_common.c >> @@ -379,8 +379,12 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, >> spin_unlock_bh(&vvs->rx_lock); >> >> err = memcpy_to_msg(msg, skb->data, bytes); >> - if (err) >> + if (err) { >> + skb_pull(skb, skb->len); >> + virtio_transport_dec_rx_pkt(vvs, skb); >> + consume_skb(skb); > > I'm not sure it's the right thing to do, if we fail to copy the content > into the user's buffer, I think we should queue it again. > > In fact, before commit 71dc9ec9ac7d ("virtio/vsock: replace > virtio_vsock_pkt with sk_buff"), we used to remove the packet from the > rx_queue, only if memcpy_to_msg() was successful. > > Maybe it is better to do as we did before and use skb_peek() at the > beginning of the loop and __skb_unlink() when skb->len == 0. Yes, i see. I'll also add test to cover this case. > > Thanks, > Stefano > >> goto out; >> + } >> >> spin_lock_bh(&vvs->rx_lock); >> >> -- >> 2.25.1 >> >
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index 30b0539990ba..ffb1af4f2b52 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -379,8 +379,12 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, spin_unlock_bh(&vvs->rx_lock); err = memcpy_to_msg(msg, skb->data, bytes); - if (err) + if (err) { + skb_pull(skb, skb->len); + virtio_transport_dec_rx_pkt(vvs, skb); + consume_skb(skb); goto out; + } spin_lock_bh(&vvs->rx_lock);