Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2895605pxv; Sun, 4 Jul 2021 01:17:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwAUut1cWzdgImQoGbKh+EhtYRQBuub0hl9NA1QvtYVDKbtSvYVDKE/xySZmuqexxauyC2J X-Received: by 2002:aa7:d413:: with SMTP id z19mr9528886edq.37.1625386644651; Sun, 04 Jul 2021 01:17:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625386644; cv=none; d=google.com; s=arc-20160816; b=MTPlQO1ie1rzzSMe6eKbnrtUAPpkRQSw7fYNKJPlzG4EwbOhWcx8E9HU6bDfiWR5qD DubmtmzHORqDds7t49Fw28wBiZPeDaxYzDRy3P3q//3dEtifrgpoa6qyb9cwYl12jIVj fuwFqor4wwgR6yPBJdP8fVl9rG2y2ap/Pj6bloIZ4kUXAJrmZMBsrz9fI6anhuZWWzTL YNTRpJd+0ABEpmBEyyFD+t+56N45qslygOtwOXEcbfuEwZknL9EjpCVeNQDobI1bWU/w UwKO1GiUxrvazc1h/wSt8b/T2xzemUsUEibd0eNfKm9J6EoSRzEjJ1HcLgtZMy65+aJa yCyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=kGEakyFUCdn/yapnPyeAmrB+mVozpPMc5PcblmevWac=; b=q3FujKXSCK7SHYWPMzwJy5vAbBUG7XCswfE8rXP3Q9Dk0oXEuWEmVMsy65bjAYnjRh 7chYKVurml2YJBMjgt7n67dkBnFYqsygoT7LRlioRuAHLsG4dD6G9EOSGDqypWxrF+OT Cx4xxbnwSo9WGHkAqIDIoeiP4+VeVuoFBGLmI6qjW9qFbMxzegWCoxeapo+qGi5hRNwx XhAK6QHSsPLfetu5cBJ8qlr7ogDuYg0gYkdjrBZv6VJemUWYCD8Wg6ZE9acxRxhv1LiJ ke9nEUT1QVj427ndRVFh9ACMtaPXcBf/H3jjiBrLFFBhfdxsXZVbX9ZRi5g/ZHz7B2VQ Vhdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kaspersky.com header.s=mail202102 header.b="4NPcU/oE"; 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=REJECT sp=REJECT dis=NONE) header.from=kaspersky.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g18si7919722eds.64.2021.07.04.01.17.00; Sun, 04 Jul 2021 01:17:24 -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=@kaspersky.com header.s=mail202102 header.b="4NPcU/oE"; 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=REJECT sp=REJECT dis=NONE) header.from=kaspersky.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229689AbhGDIQO (ORCPT + 99 others); Sun, 4 Jul 2021 04:16:14 -0400 Received: from mx12.kaspersky-labs.com ([91.103.66.155]:55506 "EHLO mx12.kaspersky-labs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbhGDIQN (ORCPT ); Sun, 4 Jul 2021 04:16:13 -0400 Received: from relay12.kaspersky-labs.com (unknown [127.0.0.10]) by relay12.kaspersky-labs.com (Postfix) with ESMTP id BA69977097; Sun, 4 Jul 2021 11:13:36 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaspersky.com; s=mail202102; t=1625386416; bh=kGEakyFUCdn/yapnPyeAmrB+mVozpPMc5PcblmevWac=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; b=4NPcU/oE47TThcAJ3OPPf7S3OgTOAa5A4AUokDHOu6Q1Wgg00L3kQqouFzA2zhm6Z YVwrlAzuZA+nNZG3LHFZR1R4euXmq1a35XwA4R5E2aqWfPcOlF32FiiY3GTyr2oHfX Vj1dBSPkkyhJSzaum/iiAT4jqxCpDyhCyEY6Jz/Bc9FHztiCsMEZlrB+iGNBq34IZT YqlijEbUxfd9Hx0coYoduueXlY5w0F0VSrCy+tE/8dl4whpDF5W74QyOAEk74fr205 XTplWZcFGL5e90vclrR4n6sor1JRHMHA/ZU8c6ZGSD+91iUhvRplQ9ZHmJX/NcT8Yy JKAJm8+TIft1g== Received: from mail-hq2.kaspersky.com (unknown [91.103.66.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client CN "mail-hq2.kaspersky.com", Issuer "Kaspersky MailRelays CA G3" (verified OK)) by mailhub12.kaspersky-labs.com (Postfix) with ESMTPS id 7A19877096; Sun, 4 Jul 2021 11:13:36 +0300 (MSK) Received: from [10.16.171.77] (10.64.68.128) by hqmailmbx3.avp.ru (10.64.67.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.14; Sun, 4 Jul 2021 11:13:36 +0300 Subject: Re: [RFC PATCH v2 0/6] Improve SOCK_SEQPACKET receive logic To: Stefan Hajnoczi , Stefano Garzarella , "Michael S. Tsirkin" , Jason Wang , "David S. Miller" , Jakub Kicinski , Andra Paraschiv , Norbert Slusarek , Colin Ian King CC: "kvm@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "oxffffaa@gmail.com" References: <20210704080820.88746-1-arseny.krasnov@kaspersky.com> From: Arseny Krasnov Message-ID: <81acbbf0-6886-7348-c4f8-06bb2f1419d2@kaspersky.com> Date: Sun, 4 Jul 2021 11:13:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210704080820.88746-1-arseny.krasnov@kaspersky.com> Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.64.68.128] X-ClientProxiedBy: hqmailmbx1.avp.ru (10.64.67.241) To hqmailmbx3.avp.ru (10.64.67.243) X-KSE-ServerInfo: hqmailmbx3.avp.ru, 9 X-KSE-AntiSpam-Interceptor-Info: scan successful X-KSE-AntiSpam-Version: 5.9.20, Database issued on: 07/04/2021 07:43:44 X-KSE-AntiSpam-Status: KAS_STATUS_NOT_DETECTED X-KSE-AntiSpam-Method: none X-KSE-AntiSpam-Rate: 0 X-KSE-AntiSpam-Info: Lua profiles 164820 [Jul 03 2021] X-KSE-AntiSpam-Info: Version: 5.9.20.0 X-KSE-AntiSpam-Info: Envelope from: arseny.krasnov@kaspersky.com X-KSE-AntiSpam-Info: LuaCore: 448 448 71fb1b37213ce9a885768d4012c46ac449c77b17 X-KSE-AntiSpam-Info: {Tracking_from_exist} X-KSE-AntiSpam-Info: {Tracking_from_domain_doesnt_match_to} X-KSE-AntiSpam-Info: 127.0.0.199:7.1.2;d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;kaspersky.com:7.1.1 X-KSE-AntiSpam-Info: Rate: 0 X-KSE-AntiSpam-Info: Status: not_detected X-KSE-AntiSpam-Info: Method: none X-KSE-Antiphishing-Info: Clean X-KSE-Antiphishing-ScanningType: Deterministic X-KSE-Antiphishing-Method: None X-KSE-Antiphishing-Bases: 07/04/2021 07:45:00 X-KSE-AttachmentFiltering-Interceptor-Info: no applicable attachment filtering rules found X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean, bases: 04.07.2021 5:50:00 X-KSE-BulkMessagesFiltering-Scan-Result: InTheLimit X-KSE-AttachmentFiltering-Interceptor-Info: no applicable attachment filtering rules found X-KSE-BulkMessagesFiltering-Scan-Result: InTheLimit X-KLMS-Rule-ID: 52 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiSpam-Interceptor-Info: not scanned X-KLMS-AntiPhishing: Clean, bases: 2021/07/04 06:12:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2021/07/04 01:03:00 #16855183 X-KLMS-AntiVirus-Status: Clean, skipped Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04.07.2021 11:08, Arseny Krasnov wrote: > This patchset modifies receive logic for SOCK_SEQPACKET. > Difference between current implementation and this version is that > now reader is woken up when there is at least one RW packet in rx > queue of socket and data is copied to user's buffer, while merged > approach wake up user only when whole message is received and kept > in queue. New implementation has several advantages: > 1) There is no limit for message length. Merged approach requires > that length must be smaller than 'peer_buf_alloc', otherwise > transmission will stuck. > 2) There is no need to keep whole message in queue, thus no > 'kmalloc()' memory will be wasted until EOR is received. > > Also new approach has some feature: as fragments of message > are copied until EOR is received, it is possible that part of > message will be already in user's buffer, while rest of message > still not received. And if user will be interrupted by signal or > timeout with part of message in buffer, it will exit receive loop, > leaving rest of message in queue. To solve this problem special > callback was added to transport: it is called when user was forced > to leave exit loop and tells transport to drop any packet until > EOR met. When EOR is found, this mode is disabled and normal packet > processing started. Note, that when 'drop until EOR' mode is on, > incoming packets still inserted in queue, reader will be woken up, > tries to copy data, but nothing will be copied until EOR found. > It was possible to drain such unneeded packets it rx work without > kicking user, but implemented way is simplest. Anyway, i think > such cases are rare. > > New test also added - it tries to copy to invalid user's > buffer. > > Arseny Krasnov (16): > af_vsock/virtio/vsock: change seqpacket receive logic > af_vsock/virtio/vsock: remove 'seqpacket_has_data' callback > virtio/vsock: remove 'msg_count' based logic > af_vsock/virtio/vsock: add 'seqpacket_drop()' callback > virtio/vsock: remove record size limit for SEQPACKET > vsock_test: SEQPACKET read to broken buffer > > drivers/vhost/vsock.c | 2 +- > include/linux/virtio_vsock.h | 7 +- > include/net/af_vsock.h | 4 +- > net/vmw_vsock/af_vsock.c | 44 ++++---- > net/vmw_vsock/virtio_transport.c | 2 +- > net/vmw_vsock/virtio_transport_common.c | 103 ++++++++----------- > net/vmw_vsock/vsock_loopback.c | 2 +- > tools/testing/vsock/vsock_test.c | 120 ++++++++++++++++++++++ > 8 files changed, 193 insertions(+), 91 deletions(-) > > v1 -> v2: > Patches reordered and reorganized. > > Signed-off-by: Arseny Krasnov > --- > cv.txt | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 cv.txt > > diff --git a/cv.txt b/cv.txt > new file mode 100644 > index 000000000000..e69de29bb2d1 Sorry, forget to remove my tmp file