Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2412432ybl; Thu, 15 Aug 2019 11:23:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqyaA0RqIzzntxGxiPZHomZ3CDumdN1v5V2P4qT05GAJ9JHVnOzJMjFm4wqcoSrrSg3X/Ato X-Received: by 2002:a17:902:760c:: with SMTP id k12mr5260955pll.206.1565893386119; Thu, 15 Aug 2019 11:23:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565893386; cv=none; d=google.com; s=arc-20160816; b=q+qjm7/cca/2b7hrVuhto2DEYo14dD7EWMZ0bD3YhwGtVpTatl4aUQKPMZkNO7vHv3 EUGGc+X0pj1Sur2nbaaqEwafyhba9e+dG7fj8chHleZeEL+zIlxvw1D82WZqf7cPqDzC rLBlqI7rOa8/a9p8eIKDFmUXPkvM6od4AqudjW2uk12+QE6Ybn6i+6JT6IEnWL33OpdQ HeaniLRBecIaPd15183wYrRbimklD1hRMNcS+aMdDtPIqrmPGcAWy4G0oggVxbaOu13c IowoDFg5ac+DOGr/G32ffivEPr2pneOghnKoeQNGRF35aMcaiVJ8Q6/246KU0+q/eZ3s VuFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=6t4FiV8ZlmFrwJ34d+212gbUZqAzntteDNGGoJ3INfA=; b=bN77momi05SlO3WWTB/30i/MYBxAwRcy2WCV0EKJX/eqFD1FbK+0fyylgjQBynGTYb DXQv8wIJl6b8Mb8sr3atUKGlij3cVX7yoRs2yv3Aw0QluNS3sZb9J3ajTyDZfBY59+0d GI3JnOio4qw1j3Zr28CHruIIRBUqp+qyCOINv2j8VMUR0FjFXkM+hc52Ym4u/4FyooTu /p90BNSweDKxjsoeoS4hA5JdioTC2IO7Ui5rfxqSxWREXzAfmlarnYIE5NsBgQV8NGmu 24TXD+izeSzPAlJMIUIs7BOnypyMl7Rsik+WJaZELm3CNL03GT3eaZ8m4dO9DifkATGR nanQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=CxfUWl6Z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x13si2237662pgr.210.2019.08.15.11.22.49; Thu, 15 Aug 2019 11:23:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=CxfUWl6Z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732456AbfHORls (ORCPT + 99 others); Thu, 15 Aug 2019 13:41:48 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:8074 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbfHORlr (ORCPT ); Thu, 15 Aug 2019 13:41:47 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Thu, 15 Aug 2019 10:41:49 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Thu, 15 Aug 2019 10:41:46 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Thu, 15 Aug 2019 10:41:46 -0700 Received: from [10.110.48.28] (172.20.13.39) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 15 Aug 2019 17:41:46 +0000 Subject: Re: [RFC PATCH 2/2] mm/gup: introduce vaddr_pin_pages_remote() To: Ira Weiny , Jan Kara CC: Andrew Morton , Christoph Hellwig , Dan Williams , Dave Chinner , Jason Gunthorpe , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , LKML , , , References: <20190812234950.GA6455@iweiny-DESK2.sc.intel.com> <38d2ff2f-4a69-e8bd-8f7c-41f1dbd80fae@nvidia.com> <20190813210857.GB12695@iweiny-DESK2.sc.intel.com> <90e5cd11-fb34-6913-351b-a5cc6e24d85d@nvidia.com> <20190814234959.GA463@iweiny-DESK2.sc.intel.com> <2cbdf599-2226-99ae-b4d5-8909a0a1eadf@nvidia.com> <20190815132622.GG14313@quack2.suse.cz> <20190815133510.GA21302@quack2.suse.cz> <20190815173237.GA30924@iweiny-DESK2.sc.intel.com> From: John Hubbard X-Nvconfidentiality: public Message-ID: Date: Thu, 15 Aug 2019 10:41:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190815173237.GA30924@iweiny-DESK2.sc.intel.com> X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1565890909; bh=6t4FiV8ZlmFrwJ34d+212gbUZqAzntteDNGGoJ3INfA=; h=X-PGP-Universal:Subject:To:CC:References:From:X-Nvconfidentiality: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=CxfUWl6Z2INpC2m03w2UoKnOg6ZKQH2HA5ushGjZOEU13Vw43HHrxeE87osanVaxN qdAm9uSPd9ZNfskJXQ/ghxfxM4pQu3bBkLIp4/SSrrEdcwZksbNBtY7eA7QobvU7L2 ANDRiX60f+5+4TNxDEr8d4VIXjvhrNIb7lt2mFC/yIFgInLWA4QawJ9PsfSRW9K2g6 +xX5DS1rirJwLRwYyT5/KnvT5SuPHdpVrbGSz2kVfwOaglAwvMnAnBX4Q6VyEwWsUF d5/yJ0G9ddLg2NEON0m8ZOoy3z1D849Fdf7OGd8/Hu+PRlOr6ERUr8qcjMgWa5N8QW +gXT8Jb48xO2Q== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/15/19 10:32 AM, Ira Weiny wrote: > On Thu, Aug 15, 2019 at 03:35:10PM +0200, Jan Kara wrote: >> On Thu 15-08-19 15:26:22, Jan Kara wrote: >>> On Wed 14-08-19 20:01:07, John Hubbard wrote: >>>> On 8/14/19 5:02 PM, John Hubbard wrote: >>>> >>>> Hold on, I *was* forgetting something: this was a two part thing, and >>>> you're conflating the two points, but they need to remain separate and >>>> distinct. There were: >>>> >>>> 1. FOLL_PIN is necessary because the caller is clearly in the use case that >>>> requires it--however briefly they might be there. As Jan described it, >>>> >>>> "Anything that gets page reference and then touches page data (e.g. >>>> direct IO) needs the new kind of tracking so that filesystem knows >>>> someone is messing with the page data." [1] >>> >>> So when the GUP user uses MMU notifiers to stop writing to pages whenever >>> they are writeprotected with page_mkclean(), they don't really need page >>> pin - their access is then fully equivalent to any other mmap userspace >>> access and filesystem knows how to deal with those. I forgot out this case >>> when I wrote the above sentence. >>> >>> So to sum up there are three cases: >>> 1) DIO case - GUP references to pages serving as DIO buffers are needed for >>> relatively short time, no special synchronization with page_mkclean() or >>> munmap() => needs FOLL_PIN >>> 2) RDMA case - GUP references to pages serving as DMA buffers needed for a >>> long time, no special synchronization with page_mkclean() or munmap() >>> => needs FOLL_PIN | FOLL_LONGTERM >>> This case has also a special case when the pages are actually DAX. Then >>> the caller additionally needs file lease and additional file_pin >>> structure is used for tracking this usage. >>> 3) ODP case - GUP references to pages serving as DMA buffers, MMU notifiers >>> used to synchronize with page_mkclean() and munmap() => normal page >>> references are fine. >> Thanks Jan, once again, for clarifying all of this! >> I want to add that I'd like to convert users in cases 1) and 2) from using >> GUP to using differently named function. Users in case 3) can stay as they >> are for now although ultimately I'd like to denote such use cases in a >> special way as well... >> > > Ok just to make this clear I threw up my current tree with your patches here: > > https://github.com/weiny2/linux-kernel/commits/mmotm-rdmafsdax-b0-v4 > > I'm talking about dropping the final patch: > 05fd2d3afa6b rdma/umem_odp: Use vaddr_pin_pages_remote() in ODP > > The other 2 can stay. I split out the *_remote() call. We don't have a user > but I'll keep it around for a bit. > > This tree is still WIP as I work through all the comments. So I've not changed > names or variable types etc... Just wanted to settle this. > Right. And now that ODP is not a user, I'll take a quick look through my other call site conversions and see if I can find an easy one, to include here as the first user of vaddr_pin_pages_remote(). I'll send it your way if that works out. thanks, -- John Hubbard NVIDIA