Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp428724rwb; Thu, 22 Sep 2022 21:26:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4ss3JEenopaIHnmwHt2E3rUJ3wTiQrMS1fSAILvXaRgN5r15vH5l+3eJqVR2dTb8NPIAPy X-Received: by 2002:a63:4b5f:0:b0:43c:428d:507c with SMTP id k31-20020a634b5f000000b0043c428d507cmr1702534pgl.607.1663907210900; Thu, 22 Sep 2022 21:26:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663907210; cv=none; d=google.com; s=arc-20160816; b=syq8Dhmx+hNED+EHynucGaFR+19VddYPKHPAH9trkATaQG48cF6mtRJwisY2KsUp10 /EyReEW40BQY0bgb18tb+/1YU2rusfynDnqZvbFvaxElAnzwBqO5KZ0b4RUIopEnEr0I +gB7m9xxQ1WcBVpa+oEog14rbwO0w3vxMU3o4GQ9gfuA3iEkC1Qw5Kh+94lF1pqVYKI5 rvp4/az4ksnpHUwMD40do6hHzh18NkRkJtocjjtJbuJNbuHMs3SYHMXxmNzpNcr7UZgA fnmqZe58O3au43jjrotH/sKJlccFnKN6TjnnOPpUKBi6rK78C+Bp0sILq5K5iVFmeBuy aBPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=+/f7rQqEMYVFzSTEHMH7lncMBYm3L3Qg9syncr2dQT4=; b=U3CDk0M+aYqbKDJgAU/sQdpE3saCgF3ASnwPegJQnXxi3vGg+dUXUBa34otwgaFirj fVg9ZPNv067LQLD/wEM62gtbI5MdTo2SqhlLBZZH6spCKsg7By3gGU8TwAMs/z/1uxno 0XUSHjBHMy6n0gtwyXng/QoQpH8Rq4Gyc68Wrl/75oe5Sn9OABMnw6gOLsd9mtzaiHYg Venyz8TSgsIln50UQBk8LMXBc6lGw1GlQ4XqXv5BeoU08cK8DKuXAK19ToX/dPIaVXBR JH9E1jVymGEFUd74X3gOrcqDQiPVE/iKWNCXnyyUKCHh7XFSiaKvrkSyMUowxzsDo9rD tohg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=jSbZR1B9; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d5-20020a656205000000b00439ae523fd2si8218101pgv.289.2022.09.22.21.26.37; Thu, 22 Sep 2022 21:26:50 -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=@linux.org.uk header.s=zeniv-20220401 header.b=jSbZR1B9; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230352AbiIWEWf (ORCPT + 99 others); Fri, 23 Sep 2022 00:22:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229810AbiIWEWe (ORCPT ); Fri, 23 Sep 2022 00:22:34 -0400 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 741B711D60C; Thu, 22 Sep 2022 21:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=+/f7rQqEMYVFzSTEHMH7lncMBYm3L3Qg9syncr2dQT4=; b=jSbZR1B9zaw3IUb4LnQOM9P7W9 LWABTG8h+HtJQW6NV9vx5y/twluuZRVUmrCCh7vfod5xUnH84BVWs3C53GmfJdKih08M3KET39+OV /DiwEDkwJYzJ9OFj5CRG/i10mcWEy2Dsxq5VdNfJas7JLzHoMtlNNj5Z7Bn0xYwAypvZmx1V6kU9/ TYTUGLCLztQVdWXDEkeoLoB/T7psEB/BVae2Ro8rnO1vWb+4MO3iEITxpiFWCwjJGZNYhJpiYo6Dg 71aOuNRb/D4sTZm3Odz8kSPVcikla0nUG3tCH7dRS5kfySFrrRtCGJ8TvsiqtlJKtx/CiIo4RWlI4 P6BRgcFw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1obaCf-002fhY-2m; Fri, 23 Sep 2022 04:22:17 +0000 Date: Fri, 23 Sep 2022 05:22:17 +0100 From: Al Viro To: Christoph Hellwig Cc: Jan Kara , John Hubbard , Andrew Morton , Jens Axboe , Miklos Szeredi , "Darrick J . Wong" , Trond Myklebust , Anna Schumaker , 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: <103fe662-3dc8-35cb-1a68-dda8af95c518@nvidia.com> <20220906102106.q23ovgyjyrsnbhkp@quack3> <20220914145233.cyeljaku4egeu4x2@quack3> <20220915081625.6a72nza6yq4l5etp@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE 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 Thu, Sep 22, 2022 at 07:38:25AM -0700, Christoph Hellwig wrote: > On Thu, Sep 22, 2022 at 03:22:48AM +0100, Al Viro wrote: > > What I'd like to have is the understanding of the places where we drop > > the references acquired by iov_iter_get_pages(). How do we decide > > whether to unpin? > > Add a iov_iter_unpin_pages that does the right thing based on the > type. (block will need a modified copy of it as it doesn't keep > the pages array around, but logic will be the same). Huh? You want to keep the type (+ direction) of iov_iter in any structure a page reference coming from iov_iter_get_pages might end up in? IDGI... BTW, speaking of lifetime rules - am I right assuming that fd_execute_rw() does IO on pages of the scatterlist passed to it? Where are they getting dropped and what guarantees that IO is complete by that point? The reason I'm asking is that here you have an ITER_BVEC possibly fed to __blkdev_direct_IO_async(), with its if (iov_iter_is_bvec(iter)) { /* * Users don't rely on the iterator being in any particular * state for async I/O returning -EIOCBQUEUED, hence we can * avoid expensive iov_iter_advance(). Bypass * bio_iov_iter_get_pages() and set the bvec directly. */ bio_iov_bvec_set(bio, iter); which does *not* grab the page referneces. Sure, bio_release_pages() knows to leave those alone and doesn't drop anything. However, what is the mechanism preventing the pages getting freed before the IO completion in this case?