Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp136560imm; Fri, 3 Aug 2018 00:34:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeUnrrB1tiTe4fJtAZms32OPVWMwSQC9kbpKM9jfTp3JBS8UYhhPnw6mHWzxMyjLR5dYMZF X-Received: by 2002:a17:902:1a9:: with SMTP id b38-v6mr2429692plb.89.1533281683396; Fri, 03 Aug 2018 00:34:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533281683; cv=none; d=google.com; s=arc-20160816; b=XVNgVIysmk68VLBoSFFgdlYVC52nPGXaxs/TGTouQMr5pJHpPo6PANMMHfZ417rOYK rkWTYbhrWXVye7qBn7yHRMea/jumeHfiHd8pzyKkL82yj57DBrQGUUvggORhtiJoGh5W mofnumbjmEvbDQHe26aLQtPORKAN/ZBbUmcWD0fqkoF5K960UUQtfB+GTYoNWY1tKc02 Fk0HVPpkdkDtXE5qqMRdIaSn0wSmYOlRS4sKiHn0n3WsICd1MFLU+pk3jd0Q5y44eGYa DMRWRZMLGvEUsXjqzE2MbKYy3nlgewbvx7z1Bt1slPbHo3YSRi9o+s8hRFfCsfisnC98 SVxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=RQTQtvTTeNFtqQwl9MnjSCfH9t5kAj82XAqaDxpELlY=; b=ztY1Ywx9PsEY1MBdHxVFE65UkyCOZSl+SVhcLkWqSGCeYrgxlxkw/6vpZMP6GhDDwA Hkay/Ekk5qfEyVmC17xDi5PvBCRnrpvPbr3W5Ejn3ffw4fkZGPF6Maqp/i88nSmaoL19 Uwu4IzmgMamAe/i3ZWsG7wrC3mKO9InA/EOunxfnHtUzYt1q+sy+9WcCxt06JyOqURCT q/9bP9DUuxKAbGU+PvfKJ9NHXnS0ZhBxBGhSK/KzaUHIZQ5pi0aOp9L/bbPvZMc3mKCZ +ZpgTJqU4YRhf5P++44iVixG9WHV5/numcWx2/ze6FJ8AQ097pt5WZo7s2Xd4CdYgeWC 9s6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f10-v6si3596986pga.559.2018.08.03.00.34.28; Fri, 03 Aug 2018 00:34:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732649AbeHCJ15 (ORCPT + 99 others); Fri, 3 Aug 2018 05:27:57 -0400 Received: from nautica.notk.org ([91.121.71.147]:34979 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728129AbeHCJ15 (ORCPT ); Fri, 3 Aug 2018 05:27:57 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 359FDC009; Fri, 3 Aug 2018 09:32:55 +0200 (CEST) Date: Fri, 3 Aug 2018 09:32:40 +0200 From: Dominique Martinet To: jiangyiwen Cc: Eric Van Hensbergen , Ron Minnich , Latchesar Ionkov , Linux Kernel Mailing List , v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org Subject: Re: [V9fs-developer] [PATCH] net/9p: avoid request size exceed to the virtqueue number in the zero copy Message-ID: <20180803073240.GA26848@nautica> References: <5B63FB4D.1050703@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5B63FB4D.1050703@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org jiangyiwen wrote on Fri, Aug 03, 2018: > Unfortunately, when the address(input and response headers) are not > at page boundary, it will need two extra entry in the zero copy, or > else it will cause sg array out of bounds. > > To avoid the problem, we should subtract two pages for maxsize. Good catch, that must have been painful to figure. Given we know how big the headers are (something like 11 or 23 bytes depending on the op/direction, it's capped by P9_IOHDRSZ at 24), couldn't we just cheat and not use the start of the buffer if we detect it's overlapping? It's probably faster to memcpy a few bytes than to use two pages for the sg list... It's definitely ugly though, just taking more margin here is probably just as good. I'm going to be picky about English again, sorry, please bear with me. > Subject: net/9p: avoid request size exceed to the virtqueue number in > the zero copy This is >72 characters so a little bit too long, if possible to shorten it. I'm also not sure 'exceed' is a noun so I probably wouldn't have understood this sentence without the rest of the message... The balance is difficult but it doesn't need to contain too much details either something like "9p/virtio: reduce transport maxsize" is simple but probably enough as it describes what is done: someone can look at the rest of the message for the justification. > Signed-off-by: Yiwen Jiang > --- > net/9p/trans_virtio.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c > index 6265d1d..63591b2 100644 > --- a/net/9p/trans_virtio.c > +++ b/net/9p/trans_virtio.c > @@ -754,11 +754,12 @@ static void p9_virtio_remove(struct virtio_device *vdev) > .cancel = p9_virtio_cancel, > /* > * We leave one entry for input and one entry for response > - * headers. We also skip one more entry to accomodate, address > - * that are not at page boundary, that can result in an extra > - * page in zero copy. > + * headers. We also skip three more entrys to accomodate "entry"'s plural is "entries", this word is in checkpatch's dictionary as a common typo > + * (input + response headers + data pages), address > + * that are not at page boundary, that can result in > + * an extra page in zero copy. > */ > - .maxsize = PAGE_SIZE * (VIRTQUEUE_NUM - 3), > + .maxsize = PAGE_SIZE * (VIRTQUEUE_NUM - 5), > .def = 1, > .owner = THIS_MODULE, > }; Thanks, -- Dominique