From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f198.google.com (mail-ot0-f198.google.com [74.125.82.198]) by kanga.kvack.org (Postfix) with ESMTP id CBA7A6B0005 for ; Mon, 18 Jun 2018 13:56:58 -0400 (EDT) Received: by mail-ot0-f198.google.com with SMTP id l11-v6so10533963oth.1 for ; Mon, 18 Jun 2018 10:56:58 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id g23-v6sor6730071ote.284.2018.06.18.10.56.57 for (Google Transport Security); Mon, 18 Jun 2018 10:56:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20180617012510.20139-1-jhubbard@nvidia.com> <20180617012510.20139-3-jhubbard@nvidia.com> <20180617200432.krw36wrcwidb25cj@ziepe.ca> <311eba48-60f1-b6cc-d001-5cc3ed4d76a9@nvidia.com> <20180618081258.GB16991@lst.de> From: Dan Williams Date: Mon, 18 Jun 2018 10:56:57 -0700 Message-ID: Subject: Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*() Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: John Hubbard Cc: Christoph Hellwig , Jason Gunthorpe , john.hubbard@gmail.com, Matthew Wilcox , Michal Hocko , Christopher Lameter , Jan Kara , Linux MM , LKML , linux-rdma On Mon, Jun 18, 2018 at 10:50 AM, John Hubbard wrote: > On 06/18/2018 01:12 AM, Christoph Hellwig wrote: >> On Sun, Jun 17, 2018 at 01:28:18PM -0700, John Hubbard wrote: >>> Yes. However, my thinking was: get_user_pages() can become a way to indicate that >>> these pages are going to be treated specially. In particular, the caller >>> does not really want or need to support certain file operations, while the >>> page is flagged this way. >>> >>> If necessary, we could add a new API call. >> >> That API call is called get_user_pages_longterm. > > OK...I had the impression that this was just semi-temporary API for dax, but > given that it's an exported symbol, I guess it really is here to stay. The plan is to go back and provide api changes that bypass get_user_page_longterm() for RDMA. However, for VFIO and others, it's not clear what we could do. In the VFIO case the guest would need to be prepared handle the revocation.