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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A97BBC6FA82 for ; Thu, 22 Sep 2022 14:32:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231817AbiIVOcX (ORCPT ); Thu, 22 Sep 2022 10:32:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231377AbiIVOcB (ORCPT ); Thu, 22 Sep 2022 10:32:01 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66770F684F; Thu, 22 Sep 2022 07:31:58 -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=/mtTNf4PXC+ykYPVOfxIiGXI0dE7me4fgbHt4EcB8iA=; b=n2t0Tta3S2zKp9yZTFKbZ9rphf NyKlU4nGzFCh/vtSf0VjfGGOZyYnQmAY6C2VSWMuh1lYMGzKJfdlihT87q7rgO+yN8QSP3acrnf0O pzK3CUy1uAzfs5PUdi36ROvFDkKPOS+9GBFBRhkfqa0BIh/fIDCxCX4SQpc61HTRFrHYmF+e5T4wE hzpecbbxEXy5fYxSKCWMbo0z4+lT106+/wRSystE+ajPaTGAL6qsCSOqyIv4AWcyAhZbLzDR/0uZu IDrNucF+k2FAFp84QyXEI2UfPseFKFQNUKimNMSO5wtOMgwXFNWpTYDz5VnHE74/7HxxkYr+vQUNO sxjfGb6g==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1obNEm-00G32R-Cq; Thu, 22 Sep 2022 14:31:36 +0000 Date: Thu, 22 Sep 2022 07:31:36 -0700 From: Christoph Hellwig To: Al Viro Cc: Christoph Hellwig , 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: <20220831041843.973026-1-jhubbard@nvidia.com> <20220831041843.973026-5-jhubbard@nvidia.com> <103fe662-3dc8-35cb-1a68-dda8af95c518@nvidia.com> <20220906102106.q23ovgyjyrsnbhkp@quack3> 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 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, Sep 14, 2022 at 04:51:17AM +0100, Al Viro wrote: > Unless I'm misreading Jan, the question is whether they should get or > pin. And I think the answer is: inside ->read_iter or ->write_iter they should neither get or pin. The callers of it need to pin the pages if they are pagecache pages that can potentially be written to through shared mappings, else a get would be enough. But the method instance should not have to care and just be able to rely on the caller making sure they do not go away. > I'm really tempted to slap > if (WARN_ON(i->data_source)) > return 0; > into copy_to_iter() et.al., along with its opposite for copy_from_iter(). Ys, I think that would be useful. And we could use something more descriptive than READ/WRITE to start with.