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 DEE47C6FA82 for ; Wed, 14 Sep 2022 16:43:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 514BE8D0006; Wed, 14 Sep 2022 12:43:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C4468D0001; Wed, 14 Sep 2022 12:43:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38C458D0006; Wed, 14 Sep 2022 12:43:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2A84D8D0001 for ; Wed, 14 Sep 2022 12:43:05 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id ED9B9AABBC for ; Wed, 14 Sep 2022 16:43:04 +0000 (UTC) X-FDA: 79911260688.06.01AA656 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf02.hostedemail.com (Postfix) with ESMTP id 779DE800B4 for ; Wed, 14 Sep 2022 16:43:04 +0000 (UTC) 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=drGd84Y88D87DtABnnd7yh6bhIO3nFxVGZfiNKSay/w=; b=NJ6SAfFns58rMbVH+azyEAlIBe P6n1bn9OXiF4fmUEUpqXGV/bE106qYmZbX/MwFVbHxtW6ssgk2PCE8UfNTQg1aWm+yynxcJ9j7g08 8/tgQ5onCzhF8MKSQaEQ6zA3aarCv+3D7yqjX8P1okh4bYNOq1WFHE1a4IQDf5KHdx5u5zA+Wymlc S+7i9ko/VpxQnZRAsQ62an08GtRr8DVSaNW3j49A/qLEWP1M+neWYX1OVsjvTIT7LfH477m66cmRa Nyt7CbCvmVkXs5Lmdv1xX0vhwGMMyYK/hJL+vP9XhDhzkKBGXkATkAHo1w7IXkb8b+clGQVzjQxRV f5T3UCDA==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1oYVTE-00GF4L-1R; Wed, 14 Sep 2022 16:42:40 +0000 Date: Wed, 14 Sep 2022 17:42:40 +0100 From: Al Viro To: Jan Kara Cc: Christoph Hellwig , 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> <20220914145233.cyeljaku4egeu4x2@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220914145233.cyeljaku4egeu4x2@quack3> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663173784; a=rsa-sha256; cv=none; b=j9KK2gwEv0SA2ClqsgbG2vVAJPF/460nv/4c6q0PPWsYe9TzEgyPhWOqWXqjCmkTCuiALu UGc0yxhhrvMmyMzBfay7zUrW/aC+pBKESLzsZl7lBl8OIKTC2wHFhpgTJvPavO21IsFrw8 xZAe4n2dk97elsclDkYdrYYYMgy4Eno= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=NJ6SAfFn; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf02.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663173784; h=from:from:sender: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=drGd84Y88D87DtABnnd7yh6bhIO3nFxVGZfiNKSay/w=; b=FA5SZ57fWmsaA7tcDq/dZ9fhHkPge2k6l7pbV5m4DhqEFsVDdk+zOdT+HaEE5G/azKPmDV fVuRjJDf8zclEGsCxmGfDkF7rXfI26OrHxVsXj+ia2W70b48r//un3tbjs1WQcctAK2rqd /PwMZNDCjsRsAw8lrBD4fhFIWZUPHlg= Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b=NJ6SAfFn; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf02.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk X-Rspam-User: X-Rspamd-Server: rspam01 X-Stat-Signature: gkuhqx6qr64pwm3gub8ej4698m53m39g X-Rspamd-Queue-Id: 779DE800B4 X-HE-Tag: 1663173784-869108 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 Wed, Sep 14, 2022 at 04:52:33PM +0200, Jan Kara wrote: > > ================================================================================= > > CASE 5: Pinning in order to write to the data within the page > > ------------------------------------------------------------- > > Even though neither DMA nor Direct IO is involved, just a simple case of "pin, > > write to a page's data, unpin" can cause a problem. Case 5 may be considered a > > superset of Case 1, plus Case 2, plus anything that invokes that pattern. In > > other words, if the code is neither Case 1 nor Case 2, it may still require > > FOLL_PIN, for patterns like this: > > > > Correct (uses FOLL_PIN calls): > > pin_user_pages() > > write to the data within the pages > > unpin_user_pages() > > > > INCORRECT (uses FOLL_GET calls): > > get_user_pages() > > write to the data within the pages > > put_page() > > ================================================================================= > > Yes, that was my point. The thing is, at which point do we pin those pages? pin_user_pages() works by userland address; by the time we get to any of those we have struct page references and no idea whether they are still mapped anywhere. How would that work? What protects the area where you want to avoid running into pinned pages from previously acceptable page getting pinned? If "they must have been successfully unmapped" is a part of what you are planning, we really do have a problem...