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 631E3ECAAD5 for ; Tue, 6 Sep 2022 10:21:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE87480274; Tue, 6 Sep 2022 06:21:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D97F780224; Tue, 6 Sep 2022 06:21:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5EDF80274; Tue, 6 Sep 2022 06:21:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B4A2580224 for ; Tue, 6 Sep 2022 06:21:09 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 88A3C160E5C for ; Tue, 6 Sep 2022 10:21:09 +0000 (UTC) X-FDA: 79881267858.15.4E462BF Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id 012EB16007A for ; Tue, 6 Sep 2022 10:21:08 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 8B1691F9B8; Tue, 6 Sep 2022 10:21:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1662459667; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JRzzxJnv5MaykTq7esKm/SId3jWkWiPAdjMo5oqrhRE=; b=KxJvAYQmECJdKHflrlphoK6jMea5m356jipctQWsyyBn2mXvuIKqE/JpJczXYmkvoH9nO8 NoOB88iSwiI2Ub8MVRt1ql+V2Du8naLMoby+IJylMg9zSLiTlT9sPsRaZXQbR44F6irWgs wfZCT1dxVKV4e5PjvHq5w10DQUscpmI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1662459667; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JRzzxJnv5MaykTq7esKm/SId3jWkWiPAdjMo5oqrhRE=; b=plZXEtxGbS1qVODpVEpx1mvVcKzPPQXJbGzq02JAcGOhoP0DN1kZuv58cv4wa0hVHaZblC 6/YkhJlMFnkIsNAA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6F33D13A7A; Tue, 6 Sep 2022 10:21:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id M/EfGxMfF2POBgAAMHmgww (envelope-from ); Tue, 06 Sep 2022 10:21:07 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 053EBA067E; Tue, 6 Sep 2022 12:21:06 +0200 (CEST) Date: Tue, 6 Sep 2022 12:21:06 +0200 From: Jan Kara To: Christoph Hellwig Cc: John Hubbard , 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: <20220906102106.q23ovgyjyrsnbhkp@quack3> 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: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662459669; a=rsa-sha256; cv=none; b=HfIiw1Pr2jF0zHITYH8zZQ8iwQva7BVrtyZZ2oM5TJ1tnlCgLvY2erZCPLvJHtBBYhdXp4 E1PmkW6LqK+8HBqekBq1xYi/oGDGo4t3+c7CXCQ/MejSS3m4/JXA4qSCviXhNJ0zwi7WJA UEY5L+hjqn6QLl44iBRsI32gKs0nV28= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=KxJvAYQm; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=plZXEtxG; spf=pass (imf08.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662459669; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JRzzxJnv5MaykTq7esKm/SId3jWkWiPAdjMo5oqrhRE=; b=ADpnX2+l77mBsrdb1GghkGw7w8YlmGHhQOMzCFoEWOfwDs2rB6LPAmNk2Gc5j4pqmDgS2T zrXnXzIW4b8HoMr+fMpGEwfHs/H0iSARHQjEAIjvHFQ4wll9IHeA+SMETdX9PTVpBHkleK EgjmZMnb9iyelyJv/ocfITd0fElMBXw= X-Stat-Signature: sfrm76ueyi66ddg3gmact58k1adryhk1 X-Rspamd-Queue-Id: 012EB16007A X-Rspamd-Server: rspam07 X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=KxJvAYQm; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=plZXEtxG; spf=pass (imf08.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none X-HE-Tag: 1662459668-98949 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 Tue 06-09-22 00:48:49, Christoph Hellwig wrote: > On Tue, Sep 06, 2022 at 12:44:28AM -0700, John Hubbard wrote: > > OK, that part is clear. > > > > > - for the pin case don't use the existing bvec helper at all, but > > > copy the logic for the block layer for not pinning. > > > > I'm almost, but not quite sure I get the idea above. Overall, what > > happens to bvec pages? Leave the get_page() pin in place for FOLL_GET > > (or USE_FOLL_GET), I suppose, but do...what, for FOLL_PIN callers? > > Do not change anyhing for FOLL_GET callers, as they are on the way out > anyway. > > 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. Are you sure about "For file systems not acquiring a reference is obviously safe"? I can see places e.g. in orangefs, afs, etc. which create bvec iters from pagecache pages. And then we have iter_file_splice_write() which creates bvec from pipe pages (which can also be pagecache pages if vmsplice() is used). So perhaps there are no lifetime issues even without acquiring a reference (but looking at the code I would not say it is obvious) but I definitely don't see how it would be safe to not get a pin to signal to filesystem backing the pagecache page that there is DMA happening to/from the page. Honza -- Jan Kara SUSE Labs, CR