Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp5387763rwb; Wed, 7 Sep 2022 01:55:17 -0700 (PDT) X-Google-Smtp-Source: AA6agR5uYKeNWlODItacgZJYG+46VjeU3L+wE1PNrEGxzRDKyv0gruVE2Fd9BbZusmyCRakVZ8l9 X-Received: by 2002:a17:902:b184:b0:172:766e:7f35 with SMTP id s4-20020a170902b18400b00172766e7f35mr2712477plr.174.1662540916793; Wed, 07 Sep 2022 01:55:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662540916; cv=none; d=google.com; s=arc-20160816; b=dvbrAj89NGDub9JA0r7Q0HE8jumyeY3JPVWNi4nzW13CBPDC0tKul2yN8iOlrvnELx hgKB2Es0psgdomxufUsShnVUxIwodPF6r76p/SWAWhSSx8p/D05iG98G70VCj+GuJgRM W0J8pjI3zW+vsR7uC8o4qDRO//oy9Ub5US6FmDLXMv3k9oztcAto38ILieP6/g8iKRE/ 8HDmHcFVi8sVhvo4lG8wXk7aINURrP7JMObq7MVvLG7UkoU0PmRz8mzvipL8WdrYq2Z7 5XP7KbYjKQFW2H8J2gEKPdoZHszprsybbNYU1DmjNmCmHZUyOcxOSmS78hsc28yBcEif iCdQ== 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=/OVlAwW7sTMujMAdfroN1GdwN81L832uh1HMrI/nvGo=; b=KmwL4sK8W/QINkuhRUZjBR0Kj2suowbJHWavCdGxIs4QEyvRjC5H3QAT+2lXrFX9rx oNK5ZMwnFP644NGwHoYpnwCsqUjjfL0sBiNHhHAXYVkhxeDOUZkvECkMhgcLeg3wTD6j i8t/NDmzhNtOaCddUqPo7+VyZxAV/gDIvVwMfCKyLj3HZmrGgkhYISgE5gCkPG9CGbxa MNJ1WzwUnNb8U4QBgy3ZckXJdb1J2cmm+QbPAM1USL0ioh8RJxdAOYkf3e7yJNoTMDZU xEmiprHyQBuKBc+anitibIg6igt/llU5pGmoT7RZyNVk/egRqcd/t5nJfs7vomRL7Dsr 3wSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=asGZyz3l; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mq15-20020a17090b380f00b001d991dfad30si11069732pjb.153.2022.09.07.01.55.03; Wed, 07 Sep 2022 01:55:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=asGZyz3l; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229608AbiIGIuV (ORCPT + 99 others); Wed, 7 Sep 2022 04:50:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbiIGIuU (ORCPT ); Wed, 7 Sep 2022 04:50:20 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7524A21821; Wed, 7 Sep 2022 01:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/OVlAwW7sTMujMAdfroN1GdwN81L832uh1HMrI/nvGo=; b=asGZyz3lnIp+c/31yhqNB3FuPy f6fsq8p0L7wSMvyxGmWAQ7k7NZXA1eW8Fz4M0BSsCva1X4pxrgUa0Jj5EZlR2l9B+vXdgDCPTT/ei hv27ApJ2tQ1Ap90kCx4akyi+6uLb9NhAhoyT9jCkH1RmNwcPq9Ca6MseOuKJ0IMa6ti04OfbSe/JT DHTLaZJKlRvDjpAARCk/hWwaebAM/2UdDrmcSqemR/RFF5H6Oz786lTv/ItQr3quy73LaWz0rz4Eb dGT3Cmwwf81BAHOyPBy3bfIK7zHFQ3qQTzQlvU5XEaKcPTYksp4/xPJnO9DpwqIAtcbV156GaV/b7 Cx8x3Nng==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVql9-004Ux0-J9; Wed, 07 Sep 2022 08:50:11 +0000 Date: Wed, 7 Sep 2022 01:50:11 -0700 From: Christoph Hellwig To: John Hubbard Cc: Christoph Hellwig , Andrew Morton , Jens Axboe , Alexander Viro , Miklos Szeredi , "Darrick J . Wong" , Trond Myklebust , Anna Schumaker , Jan Kara , David Hildenbrand , Logan Gunthorpe , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, LKML Subject: Re: [PATCH v2 4/7] iov_iter: new iov_iter_pin_pages*() routines Message-ID: References: <20220831041843.973026-1-jhubbard@nvidia.com> <20220831041843.973026-5-jhubbard@nvidia.com> <103fe662-3dc8-35cb-1a68-dda8af95c518@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, Sep 06, 2022 at 12:58:59AM -0700, John Hubbard wrote: > > For FOLL_PIN callers, never pin bvec and kvec pages: For file systems > > not acquiring a reference is obviously safe, and the other callers will > > need an audit, but I can't think of why it woul ever be unsafe. > > In order to do that, one would need to be confident that such bvec and kvec > pages do not get passed down to bio_release_pages() (or the new > bio_unpin_pages()). Also, I'm missing a key point, because today bvec pages get > a get_page() reference from __iov_iter_get_pages_alloc(). If I just skip > that, then the get/put calls are unbalanced... Except that for the most relevant callers (bdev and iomap) we never end up in __iov_iter_get_pages_alloc. What I suggest is that, with the move to the pin helper, we codify that logic. For callers of the bio_iov_iter_pin_pages helper, the corresponding bio_unpin_pages helper will encapsulate that logic. For direct calls to iov_iter_pin_pages, we should add a iov_iter_unpin_pages helper that also encapsulates the logic. The beauty is that this means the caller itself does not have to care about any of thise, and the logic is in one (well two due to the block special case that reuses the bio_vec array for the pages space) place. > I can just hear Al Viro repeating his points about splice() and vmsplice(), > heh. :) splice does take these references before calling into the file system (see my reply to Jan).