From patchwork Sun Mar 5 20:04:45 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arseniy Krasnov X-Patchwork-Id: 6124 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1513945wrd; Sun, 5 Mar 2023 12:12:05 -0800 (PST) X-Google-Smtp-Source: AK7set8cFM/RmX1RsLNLVLBkhkRgF6IVNnnfClkY3UkVEu/lXxGeTzwUMgwQnr8gdTEo8jA384KS X-Received: by 2002:a17:906:246:b0:8b1:fc1a:7d21 with SMTP id 6-20020a170906024600b008b1fc1a7d21mr10788911ejl.5.1678047124996; Sun, 05 Mar 2023 12:12:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678047124; cv=none; d=google.com; s=arc-20160816; b=HDjbzNSI82MmF8urn+9slGT3YU4kvMO0OFghl3khVftXzB2Hh2OKG0Ynv5JARgSNwG yc9kqcM7q/sIUuso8L1RsjHGBs7XI/j1aemCn7j4rE1iHV1s/Hw+eb4lg02OBoA02ci/ axot33kqlfEUS5LAostePC2RRBJUNYjL7fSY2cmxFIZmQ7qupUDLMLypR57/aP5z4CvO sP3ofjsY6uSu6DnDVpFIhD9wfm06sL+hWGCojSec2/UH4A3UOE4B9aErVKYrZjl0lqmY 38b12AlocPxLhLv/crlHueNKQi4ADF3yrq7FRNBvv7Qmv6ZX8uQ4K0VlrWjcp31BHr08 zpzQ== 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 :content-language:user-agent:mime-version:date:message-id :dkim-signature; bh=HJc6SOI5RX3x6uTZNKZKhZWULwHOcmQ+GQH6cylyxbA=; b=ZqNcUzP0cj3/Ffb+M6/dA5q59P9kp5QaPGWvQZUUJB6Z4kfAg4cMRCsQVI3rgGpmqQ zPRQPBZcrQ6vKPFK29rdilLjNEBFSc6it7E2CVHCikrwhWLGekqzVKX5OgLSUnsrlAQY lYQvID9mO2dPkT0eqjYkhDMx3TgVFd8saREw7MzPLCzDfPrtvmCBIB/1EFiV1UavHlIa aqFvhIuQ+B9ltlfstDg5JD6Yc7KOErSIKYwbWgymZBl7cPm164nT0gA2YYkF5Iv4hDim bwhkwRR5tRF6oCs/fws+aMI10wrrkJ1JgtiPBUV0ttswqbWsVk7wW9R1Jkd4DyEOzQQx U65g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=MKH3GAre; 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 z27-20020a170906241b00b008dad3ab54fcsi7578680eja.400.2023.03.05.12.11.41; Sun, 05 Mar 2023 12:12:04 -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=MKH3GAre; 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 S229616AbjCEUHy (ORCPT + 99 others); Sun, 5 Mar 2023 15:07:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbjCEUHw (ORCPT ); Sun, 5 Mar 2023 15:07:52 -0500 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98AA916AD3; Sun, 5 Mar 2023 12:07:48 -0800 (PST) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id A395F5FD04; Sun, 5 Mar 2023 23:07:45 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1678046865; bh=HJc6SOI5RX3x6uTZNKZKhZWULwHOcmQ+GQH6cylyxbA=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=MKH3GAre/bXpUfp/gEA84lbVBHhrYRHZBzoJg+Okm7xqYI+czrX71EzhYe8sFniNk DDNcoy+YQ75czEIUd4KbrxCuRBo/MroVSesCn55keVJ+zuMaMPoi9EO8YWm+BswKnR a2dn8+8i2SLOcAe8ixZ7aE2zMxlOQLnGSOOJS55YrHXuevwqxAN26ani4DWMsvjHhP dbkneNJHwSRgt1nTvCJZpMHkNZP0Xc3+6r10Rt02dTfG0dKMCwDidnVkC88xTwDK6E r0QbcjaDDt4CszFaApUAC4ZBg2TYcJgmZOxmzHoAuZd4v2qaTPVkjxYMJG9l6BSH89 gvzu43ryxZqfA== 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:07:40 +0300 (MSK) Message-ID: Date: Sun, 5 Mar 2023 23:04:45 +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 To: Stefan Hajnoczi , Stefano Garzarella , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Bobby Eshleman CC: , , , , , , From: Arseniy Krasnov Subject: [RFC PATCH v2 0/4] virtio/vsock: fix credit update logic 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759559942045304201?= X-GMAIL-MSGID: =?utf-8?q?1759559942045304201?= Hello, this patchset fixes three things in skbuff handling: 1) Current implementation of 'virtio_transport_dec_rx_pkt()': value to update 'rx_bytes' and 'fwd_cnt' is calculated as: skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len; i'm a little bit confused about subtracting 'skb->len'. It is clear, that difference between first two components is number of bytes copied to user. 'skb_headroom()' is delta between 'data' and 'head'. 'data' is incremented on each copy data to user from skb by call 'skb_pull()' (at the same moment, 'skb->len' is decremented to the same amount of bytes). 'head' points to the header of the packet. But what is purpose of 'skb->len' here? For SOCK_STREAM is has no effect because this logic is called only when 'skb->len' == 0, but for SOCK_SEQPACKET and other future calls i think it is buggy. 2) For SOCK_SEQPACKET all sk_buffs are handled only once - after dequeue each sk_buff is removed, so user will never read rest of the data. Thus we need to update credit parameters of the socket ('rx_bytes' and 'fwd_cnt') like whole sk_buff is read - so call 'skb_pull()' for the whole buffer. 3) For SOCK_STREAM when 'memcpy_to_msg()' fails it fixes 'rx_bytes' update (like in 2)) and frees current skbuff. Test is also added to vsock_test. It does two attempts to read data from socket - first attempt to invalid buffer (kernel must drop skb). Second attempt is performed with valid buffer and MSG_DONTWAIT flag. If socket's queue will be empty (skbuff was dropped due to 'memcpy_to_msg()' fail and 'rx_bytes' which controls data waiting set to 0), such call will return immediately with EAGAIN. Link to v1 on lore: https://lore.kernel.org/netdev/c2d3e204-89d9-88e9-8a15-3fe027e56b4b@sberdevices.ru/ Change log: v1 -> v2: - For SOCK_SEQPACKET call 'skb_pull()' also in case of copy failure or dropping skbuff (when we just waiting message end). - Handle copy failure for SOCK_STREAM in the same manner (plus free current skbuff). - Replace bug repdroducer with new test in vsock_test.c Arseniy Krasnov (4): virtio/vsock: fix 'rx_bytes'/'fwd_cnt' calculation virtio/vsock: remove all data from sk_buff virtio/vsock: free skb on data copy failure test/vsock: invalid buffer tests net/vmw_vsock/virtio_transport_common.c | 10 ++- tools/testing/vsock/vsock_test.c | 106 ++++++++++++++++++++++++ 2 files changed, 113 insertions(+), 3 deletions(-)