From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 974B6C433EF for ; Fri, 8 Apr 2022 19:09:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2395A6B0072; Fri, 8 Apr 2022 15:09:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E92A6B0073; Fri, 8 Apr 2022 15:09:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 088E66B0074; Fri, 8 Apr 2022 15:09:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id E9B646B0072 for ; Fri, 8 Apr 2022 15:09:46 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AE4D31838DBE4 for ; Fri, 8 Apr 2022 19:09:46 +0000 (UTC) X-FDA: 79334651172.27.CBB9F93 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf21.hostedemail.com (Postfix) with ESMTP id 481CA1C0006 for ; Fri, 8 Apr 2022 19:09:46 +0000 (UTC) Received: by mail-qt1-f178.google.com with SMTP id c4so11504127qtx.1 for ; Fri, 08 Apr 2022 12:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=91CXBQ+QrrLDOnPHUKIzRlaTu5VpTvLlE8RRdbceTKE=; b=Pea+YagxkPeueG0equs+40ADF1bGt2mGTubU7yEGQ9D5EZzlKZj3yLLBo1bo+tUp3t l01fKxrkAr9RsNHd2kJktq57jwPNwMsRwRZv0HZ8L3ZNsD5+79fz0NJpBxfqFObARLyb mpDpmII4pvnnZVMpYArpf51d82RzJwVat/cd59joy08nQkusIHZROV8kik/ENQmIW+h7 ntuwZdlOyF13ckkPtdzMThkDE5Au7ZOQEOA15QzEsP0GSoEzkN6qsyw9L8Yc6rrmM0Mp DiSae7DtuJBTCpFMPMEmAQfNuTA8mQHb9uIpHIXe7PZj05pUCqhxSlfAO8L247TOo7aS Km8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=91CXBQ+QrrLDOnPHUKIzRlaTu5VpTvLlE8RRdbceTKE=; b=TPQ28sGiAIpsa4M11x097rm7XcLdeYO9rFPz/ggpfsjYrH0ZZ8DefXyYyiALZfEkRw q07+ThOJ3dIN/xAAz1syMa/r2PKm1uYztoUytAcwLjkJIGihmfPSlCbj3F5Gh31e04qC ZSSXrVL51gfbUIwyhAZXWhmXCwdHmRbzf+rtRSfESplJ0C8E5OSzcyjWUp1Lp+Dpo6LB LZ/zPlDvx8Qj5WlX19iJ1isgbYc01inUoDqe1rZRyzosfQB/lnZPkCXt/gHyXkyrucIR B6dHpys+nqY7GVPsTc4ckloU+/OFLrbg55dBAbsbj+fcljkfljpzP2hQBG0+wdIYYo1v glHQ== X-Gm-Message-State: AOAM530pP8xReYC1VeNB3F7BUqI2NI6lgLm5x75fnB4ggEG72JbT7hcZ 93A4LKBqHQVGX+2ZNkJM7flafw== X-Google-Smtp-Source: ABdhPJzea53eTcF7VeofLNU82BNlFWAWkd0eT1DoksHxj+Lxar1co0V5fVEZCpnUJtJil3Uog6zHIw== X-Received: by 2002:ac8:5c90:0:b0:2e2:15c0:a5f3 with SMTP id r16-20020ac85c90000000b002e215c0a5f3mr17316917qta.332.1649444985335; Fri, 08 Apr 2022 12:09:45 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id v3-20020a05622a014300b002e1dcd4cfa9sm19653356qtw.64.2022.04.08.12.09.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 12:09:44 -0700 (PDT) Date: Fri, 8 Apr 2022 12:09:32 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Chuck Lever III cc: Hugh Dickins , Andrew Morton , Mark Hemment , Patrice CHOTARD , Mikulas Patocka , Lukas Czerner , Christoph Hellwig , "Darrick J. Wong" , Linux-MM , Linux NFS Mailing List , "linux-fsdevel@vger.kernel.org" Subject: Re: Regression in xfstests on tmpfs-backed NFS exports In-Reply-To: Message-ID: <8058d02d-d8b2-4d7a-a535-a78719e996@google.com> References: <673D708E-2DFA-4812-BB63-6A437E0C72EE@oracle.com> <11f319-c9a-4648-bfbb-dc5a83c774@google.com> <2B7AF707-67B1-4ED8-A29F-957C26B7F87A@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: t8gxagp7bc545sqqg944bt59gxjyprhu X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 481CA1C0006 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Pea+Yagx; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf21.hostedemail.com: domain of hughd@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=hughd@google.com X-Rspam-User: X-HE-Tag: 1649444986-329881 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 8 Apr 2022, Chuck Lever III wrote: > > On Apr 7, 2022, at 6:26 PM, Hugh Dickins wrote: > > On Thu, 7 Apr 2022, Chuck Lever III wrote: > >> > >> 847 static int > >> 848 nfsd_splice_actor(struct pipe_inode_info *pipe, struct pipe_buffer *buf, > >> 849 struct splice_desc *sd) > >> 850 { > >> 851 struct svc_rqst *rqstp = sd->u.data; > >> 852 struct page **pp = rqstp->rq_next_page; > >> 853 struct page *page = buf->page; > >> 854 > >> 855 if (rqstp->rq_res.page_len == 0) { > >> 856 svc_rqst_replace_page(rqstp, page); > >> 857 rqstp->rq_res.page_base = buf->offset; > >> 858 } else if (page != pp[-1]) { > >> 859 svc_rqst_replace_page(rqstp, page); > >> 860 } > >> 861 rqstp->rq_res.page_len += sd->len; > >> 862 > >> 863 return sd->len; > >> 864 } > >> > >> rq_next_page should point to the first unused element of > >> rqstp->rq_pages, so IIUC that check is looking for the > >> final page that is part of the READ payload. > >> > >> But that does suggest that if page -> ZERO_PAGE and so does > >> pp[-1], then svc_rqst_replace_page() would not be invoked. > > To put a little more color on this, I think the idea here > is to prevent releasing the same page twice. It might be > possible that NFSD can add the same page to the rq_pages > array more than once, and we don't want to do a double > put_page(). > > The only time I can think this might happen is if the > READ payload is partially contained in the page that > contains the NFS header. I'm not sure that can ever > happen these days. I'd have thought that if a page were repeated, then its refcount would have been raised twice, and so require a double put_page(). But it's no concern of mine. The only thing I'd say is, if you do find a good way to robustify that code for duplicates, please don't make it conditional on ZERO_PAGE - that's just a special case which I mis-introduced and is now about to go away. > > > > We might be able to avoid that revert, and go the whole way to using > > iov_iter_zero() instead. But the significant slowness of clear_user() > > relative to copy to user, on x86 at least, does ask for a hybrid. > > > > Suggested patch below, on top of 5.18-rc1, passes my own testing: > > but will it pass yours? It seems to me safe, and as fast as before, > > but we don't know yet if this iov_iter_zero() works right for you. > > Chuck, please give it a go and let us know. > > Applied to stock v5.18-rc1. The tests pass as expected. Great, thanks a lot, I'll move ahead with sending akpm the patch with a proper commit message. Hugh