Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3900407pxv; Mon, 5 Jul 2021 08:24:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJiBGHxRboOij0JmYiiv7TBxXjW23xrDoBKcWZ6vJKt9MBmcgN/eJPv4fiYevuQGV0lZ0l X-Received: by 2002:a05:6e02:1a02:: with SMTP id s2mr11232989ild.76.1625498669947; Mon, 05 Jul 2021 08:24:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625498669; cv=none; d=google.com; s=arc-20160816; b=F9MR2vTUzJeiLm+UsQ5phBh/MaSaLo7LCU43XpGDSS9cMdpZC+ctyZ8iDaAl9W6RpQ HIRKRIEJPqVerjAimWin8EdrknefJc27yr194IpsEZK9Rtz9E8rKDpqx1iljj6fB/b4o WoWUs6eyifVFKbIXCgu6YpwTMMiuIMGWlPFLQDQLK3XKouIOp+xFdDw5NP5HpnDxAj8y uovAj6NMmTYUCaOORC4kIoNkzGAQ+S5r1GQUUsW2NJLqCu6bDYWgUEA19ls32fXgk6d8 JgD278H/bOmChIIoqi9UgKaFagKdpJ5gPw69rD3QAD8aw7xVYJAb0ciyB9ve8v/PblKR 2z2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=r2imsBDLHS8rC/hkSxHiuEVGdRV9OR2l0LhTihLqoT4=; b=m+13xc+d4LRsdhF22ArufADh4jXWVYaW7yl/rqkyU4cRU/uvsLENgQAweyWnfJHAnI j22S43TB22WiV6kBjlCLg4Jwz/2ggrsseMkDJHADwW9r6ug/uZjw67QEdUBgcM9miBpN 3QRonRjc2zBShdZQMTV1CvwgcSmJ3ei/S8mQhDc5gcL6+L4VMRryyCM5/rOmz96KXe+J FVfzNnt6SR3cVrDR40D9l26waEEVy9TLHC6qom5J9Z8btIugCp+AoL4rOl+wj+vbr1L9 LuWfE/glW4h/SGHKc3PrqQX4PDjqW8VKXzBvLWoEnIrDwXXyx7iUg0BBaBtVedZBUlJW 5SiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Unwb6ET9; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o20si15521687ill.82.2021.07.05.08.24.18; Mon, 05 Jul 2021 08:24: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=@redhat.com header.s=mimecast20190719 header.b=Unwb6ET9; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231721AbhGEP0U (ORCPT + 99 others); Mon, 5 Jul 2021 11:26:20 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:42290 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231535AbhGEP0U (ORCPT ); Mon, 5 Jul 2021 11:26:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625498622; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r2imsBDLHS8rC/hkSxHiuEVGdRV9OR2l0LhTihLqoT4=; b=Unwb6ET9HOjfTYIqza2Fw9Pi1JhaNNTIA/ORnuPmhnr5PoJJAZ7NnPugZVtjnMrlz9yCQe VrZPe1XM7+yx8AmnrBkqgl/EHBGIKZAT4MuuL/jxqgqt5CogRCvS77sM8rEpXvbHWscNJN ECvt9HwgAbKQHiec3hZVXgHXWMtGD7o= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-3-3LyG42L3NOq-2bf94pPbYA-1; Mon, 05 Jul 2021 11:23:41 -0400 X-MC-Unique: 3LyG42L3NOq-2bf94pPbYA-1 Received: by mail-wm1-f72.google.com with SMTP id n37-20020a05600c3ba5b02901fe49ba3bd0so105259wms.1 for ; Mon, 05 Jul 2021 08:23:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=r2imsBDLHS8rC/hkSxHiuEVGdRV9OR2l0LhTihLqoT4=; b=ug8r9ZEP8woZse+76r9tYkPAM0BTOzt5E6u4kWKx/8cXw30Oi0oNJD3J7Kdi/nSt1y pcPacL51LVMSFoZ3lpFH4XpplopYWFZmDdRTOguEj6uPr88sBdF1YcrdSMjyyM76pWXO TtjaLs3fz8cAfy90FJAk1sNMaBvmkD44GhllD+ewngtm07lqUSguYM44iIYIB7mz2Cw3 +5pJMTeBkHkZZnnC+EmBAaLXXG8PSQBANvXyQu65PQdJ+pZCCg+c4SdupXbWXNYIho7o u6bbyURwkLfrsMEiddsvZP9avbzwGiDbBYNy3EQSxfZkr9IUqqrGsoHI5asYVMtYXVD/ NaFw== X-Gm-Message-State: AOAM5314ZV0MTircuY3oCgjOp9J7phaDbMTtoFtNB7BvIslCuZcmqzV1 0ZONFAgk3GgLas7+GtaxerinXk3AblR2Nj7Emv7tvxr+uQqc8Ht+r/jZkXQvsY5o+5vMvYoqPvg /6uzMMm5Rp6a84Lgzc7XnPEhc X-Received: by 2002:a1c:ed08:: with SMTP id l8mr15084297wmh.38.1625498620562; Mon, 05 Jul 2021 08:23:40 -0700 (PDT) X-Received: by 2002:a1c:ed08:: with SMTP id l8mr15084280wmh.38.1625498620313; Mon, 05 Jul 2021 08:23:40 -0700 (PDT) Received: from steredhat (host-87-7-214-34.retail.telecomitalia.it. [87.7.214.34]) by smtp.gmail.com with ESMTPSA id y8sm13359781wrr.76.2021.07.05.08.23.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jul 2021 08:23:39 -0700 (PDT) Date: Mon, 5 Jul 2021 17:23:36 +0200 From: Stefano Garzarella To: Arseny Krasnov Cc: "Michael S. Tsirkin" , Stefan Hajnoczi , 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" Subject: Re: [MASSMAIL KLMS]Re: [RFC PATCH v2 0/6] Improve SOCK_SEQPACKET receive logic Message-ID: <20210705152336.ibv4ret3d2dyhdpc@steredhat> References: <20210704080820.88746-1-arseny.krasnov@kaspersky.com> <20210704042843-mutt-send-email-mst@kernel.org> <20210704055037-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 05, 2021 at 01:48:28PM +0300, Arseny Krasnov wrote: > >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 It was the same concern I had with the series that introduced SEQPACKET for vsock, which is why I suggested to wait until the message is complete, before copying it to the user's buffer. IIUC, with the current upstream implementation, we don't have this problem, right? I'm not sure how to fix this, other than by keeping all the fragments queued until we've successfully copied them to user space, which is what we should do without this series applied IIUC. Stefano