Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3704333pxv; Mon, 5 Jul 2021 03:49:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymhte1KyrcdyV37AtyVqJnrOgJlwTEzIdyA2EZFo4RJNCHxtlLAD1wJ3QRkiyEgImbnL1L X-Received: by 2002:a92:c68c:: with SMTP id o12mr10217980ilg.21.1625482169535; Mon, 05 Jul 2021 03:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625482169; cv=none; d=google.com; s=arc-20160816; b=MwloI8BcUJSoU74UsqMa+HrPDym3VP+rFmFDuvuCcSXBYiKw4R58SLvu4WKxT7Kj5Y wWxhxykUpAscbJxBDYrKIb9RdNrXGYmRVXNeKUYGWgJI2qAvSliIEDjSVcTO2wSaFP1E YWFuy6ZRbPFXvA+lcawIwQNDtSA/qib+SYYNwm1zIr6r+eI6ONaDR46//fXc7Wi9BS5t 09UUyqkItl/Rs4xLFj19g1l09K1yhyAW8cu89RjibI3z2Vs15LoXlMiSmD8hICoSn+Wf RNwZ1aUHpEMZ//7Q47cP17noaUagge2ZgudfsZxUYtB9zByxXkTpYMooa4TJkZqnIItJ x3tg== 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=r5Z1vzpteloz/5230YXT1DtK09ZfwpWzllYWGELadvQ=; b=y85Zi1dlRUXLy9kh/tdHLQdrkRneHxRlGnjhEcYlmuVE4pBP2gjn+OYl76JGxRH7Hn +7Zh//ZC/edeEJYiFEDLGJ6nsgTJ5efFuxExQgvyM87Eg+Syp/mEdVySR8KpMoX0iX6U 5MnsXOsMEnP/hoaP2lByEDU0rlZC7iweOHni5kQ3nGr4gTc93dplDNZhp4t4UHsvNs64 NnP10IvMAHQCSOmKDIZdKOk6NAf3ESJJCPkLV1cPUcschUdsiZuxRqawxaaN8IqnoVel AEJmkFe86gPLUDaBqT2GV/MRTAjj+whbtwGq9Nr1FOsHcSUTAc6Dfnvn6cYDa0AXxaws 3eMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kaspersky.com header.s=mail202102 header.b=lBRCPbvL; 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 n19si2109778jaj.117.2021.07.05.03.49.18; Mon, 05 Jul 2021 03:49:29 -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=lBRCPbvL; 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 S231237AbhGEKvK (ORCPT + 99 others); Mon, 5 Jul 2021 06:51:10 -0400 Received: from mx12.kaspersky-labs.com ([91.103.66.155]:16018 "EHLO mx12.kaspersky-labs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230482AbhGEKvJ (ORCPT ); Mon, 5 Jul 2021 06:51:09 -0400 Received: from relay12.kaspersky-labs.com (unknown [127.0.0.10]) by relay12.kaspersky-labs.com (Postfix) with ESMTP id 5970675FD6; Mon, 5 Jul 2021 13:48:31 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaspersky.com; s=mail202102; t=1625482111; bh=r5Z1vzpteloz/5230YXT1DtK09ZfwpWzllYWGELadvQ=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; b=lBRCPbvL+OhqDXqtnOvFsBwWS1MIjNEI+9b5cqqKB5AylqgOtGwAhfbRfkrtI9kC2 Ow1Ma7MbK5pODy7JF7lLiHJ3kgeGkBCIRM6FeKL/UVRSU/COJr0aDjsfy/TBkTDpey TYbifR0wiNkvIheTcUJFf470XUewWFYMhI9Jg0cZ73X3iftUXcSW5uFRqVhO5y9b6U 9OLShgveInxCunlShptWierzjPubf7v1428flenPj00F23d5Hz3XVZqbGWsBgdNnNF 9XIEUaTlwyUsG3/HE91mVoguJSV80cZc9KF0ePFeRPj9M4vsyLB2+FI6l+gRFBSipq qRmcz/1M3orLA== 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 A240775FAE; Mon, 5 Jul 2021 13:48:30 +0300 (MSK) Received: from [10.16.171.77] (10.64.64.121) 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; Mon, 5 Jul 2021 13:48:29 +0300 Subject: Re: [MASSMAIL KLMS]Re: [RFC PATCH v2 0/6] Improve SOCK_SEQPACKET receive logic To: "Michael S. Tsirkin" CC: Stefan Hajnoczi , Stefano Garzarella , Jason Wang , "David S. Miller" , Jakub Kicinski , Andra Paraschiv , Norbert Slusarek , Colin Ian King , "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> <20210704042843-mutt-send-email-mst@kernel.org> <20210704055037-mutt-send-email-mst@kernel.org> From: Arseny Krasnov Message-ID: Date: Mon, 5 Jul 2021 13:48:28 +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: <20210704055037-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.64.64.121] 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/05/2021 10:23:33 X-KSE-AntiSpam-Status: KAS_STATUS_NOT_DETECTED X-KSE-AntiSpam-Method: none X-KSE-AntiSpam-Rate: 0 X-KSE-AntiSpam-Info: Lua profiles 164836 [Jul 05 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: d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;127.0.0.199:7.1.2;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/05/2021 10:25: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: 05.07.2021 7:14: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/05 06:23:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2021/07/05 06:33:00 #16857317 X-KLMS-AntiVirus-Status: Clean, skipped Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04.07.2021 12:54, Michael S. Tsirkin wrote: > On Sun, Jul 04, 2021 at 12:23:03PM +0300, Arseny Krasnov wrote: >> On 04.07.2021 11:30, Michael S. Tsirkin wrote: >>> On Sun, Jul 04, 2021 at 11:08:13AM +0300, 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. >>> Sorry about commenting late in the game. I'm a bit lost >>> >>> >>> SOCK_SEQPACKET >>> Provides sequenced, reliable, bidirectional, connection-mode transmission paths for records. A record can be sent using one or more output operations and received using one or more input operations, but a single operation never transfers part of more than one record. Record boundaries are visible to the receiver via the MSG_EOR flag. >>> >>> it's supposed to be reliable - how is it legal to drop packets? >> Sorry, seems i need to rephrase description. "Packet" here means fragment of record(message) at transport >> >> layer. As this is SEQPACKET mode, receiver could get only whole message or error, so if only several fragments >> >> of message was copied (if signal received for example) we can't return it to user - it breaks SEQPACKET sense. I think, >> >> in this case we can drop rest of record's fragments legally. >> >> >> Thank You > Would not that violate the reliable property? IIUC it's only ok to > return an error if socket gets closed. Just like e.g. TCP ... > Sorry for late answer, yes You're right, seems this is unwanted drop... Lets wait for Stefano Garzarella feedback Thank You > >>> >>>> 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 >>>> -- >>>> 2.25.1 >