From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=EDyl=IQ=lists.01.org=linux-nvdimm-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID,
	DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id BA471C433DB
	for <linux-nvdimm@archiver.kernel.org>; Thu, 18 Mar 2021 17:03:17 +0000 (UTC)
Received: from ml01.01.org (ml01.01.org [198.145.21.10])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.kernel.org (Postfix) with ESMTPS id 48E3164DD8
	for <linux-nvdimm@archiver.kernel.org>; Thu, 18 Mar 2021 17:03:17 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 48E3164DD8
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org
Received: from ml01.vlan13.01.org (localhost [IPv6:::1])
	by ml01.01.org (Postfix) with ESMTP id EB3AC100EB35C;
	Thu, 18 Mar 2021 10:03:16 -0700 (PDT)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::52a; helo=mail-ed1-x52a.google.com; envelope-from=dan.j.williams@intel.com; receiver=<UNKNOWN> 
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))
	(No client certificate requested)
	by ml01.01.org (Postfix) with ESMTPS id 6F9EE100EB35A
	for <linux-nvdimm@lists.01.org>; Thu, 18 Mar 2021 10:03:14 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id e7so7542411edu.10
        for <linux-nvdimm@lists.01.org>; Thu, 18 Mar 2021 10:03:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=intel-com.20150623.gappssmtp.com; s=20150623;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ncWZPnyeBiWOdZ1rqhn/kolCjnyW0fSBUFhdCHieBDM=;
        b=t7GWySP7B7GjasZeOxZIv+aUzBxCH4W8Be/Cy5Zw06Sb0yLfg7nYnjvi+LMPGBm+iy
         XU1pC+kO/ONtX1X5jRrh3oWqaYzP8VrOMDMSdbE3sEb/K2OPCuj32WF8LUbnS7WUUkER
         f/4lOy6HJMClpiu6qjhKKZtFhrjrVQKGnwMR9WtL5EBd/KCh9of1N1ll67hR0YZeKLV3
         KK/KNTdOTBqCM8AiipskMe6qhvDgT+aMxNjpBn2xW5c+VJQ6/8OIeFu7onCvsXGWhx2J
         VnXJ1RI+QZOWD8OVrk9m6l/pxM2WFTO5fyo5bQSttDcPLA4PDtmJKUqI3QzfSqUqh75G
         Wkuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ncWZPnyeBiWOdZ1rqhn/kolCjnyW0fSBUFhdCHieBDM=;
        b=UCuKnVB0W6lYKBO9ir38O8ze2LtzhqXLLUt5aXxHGbKs+vupYzOGYWFnb4ylH/SKUV
         7ji0EDsqJbUx+IJzyKKBKenZwpO17fwUFvZVfPZFaA9jR/FLhbxxv0Oh40i9xUYtwQoc
         sOw7RCOMMGEtDTj69dJw05SWykPJWusJ3jiPHL872kd8XqnA5MLOfqa3f2Ui7UTXviji
         GUWRaVjQiZS0WyQ5WYqC00X7tb/RqMtj6m60TtDDXBt+4iShrEv78YzkroTZd+c4+4Hs
         yRL/TN2CCOVMgEQuNIDjATu73zULXyHsQQcUwHcKGnyYX8qgEozFx5YhQ6w3jJDf0PnW
         /uCw==
X-Gm-Message-State: AOAM531Ktiml5on6fPB4M8Ms7JxxpCYlmpPxaF6ptAKyntgEJsyrrDLe
	e6HzLaGuk45FLwHj0RX7PfOVwFGf2O1RPmjvcOTJjg==
X-Google-Smtp-Source: ABdhPJxuNsdRluFA0/M5LLOxZ8cJZSLdLyy24eAaZULCocflm5Th9Ab5OwvvWKq3EP121Lq2ytUniLx2mfNJE2c/9s0=
X-Received: by 2002:a05:6402:1713:: with SMTP id y19mr3827680edu.52.1616086991914;
 Thu, 18 Mar 2021 10:03:11 -0700 (PDT)
MIME-Version: 1.0
References: <161604048257.1463742.1374527716381197629.stgit@dwillia2-desk3.amr.corp.intel.com>
 <161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com>
 <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com>
In-Reply-To: <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Thu, 18 Mar 2021 10:03:06 -0700
Message-ID: <CAPcyv4g8=kGoQiY14CDEZryb-7T1_tePnC_-21w-wTfA7fQcDg@mail.gmail.com>
Subject: Re: [PATCH 3/3] mm/devmap: Remove pgmap accounting in the
 get_user_pages_fast() path
To: Joao Martins <joao.m.martins@oracle.com>
Message-ID-Hash: 2G355OFILVBITKG7Z5SDUAX2HTUHO7AO
X-Message-ID-Hash: 2G355OFILVBITKG7Z5SDUAX2HTUHO7AO
X-MailFrom: dan.j.williams@intel.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header
CC: Jason Gunthorpe <jgg@ziepe.ca>, Christoph Hellwig <hch@lst.de>, Shiyang Ruan <ruansy.fnst@fujitsu.com>, Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>, Andrew Morton <akpm@linux-foundation.org>, david <david@fromorbit.com>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux MM <linux-mm@kvack.org>, linux-nvdimm <linux-nvdimm@lists.01.org>
X-Mailman-Version: 3.1.1
Precedence: list
List-Id: "Linux-nvdimm developer list." <linux-nvdimm.lists.01.org>
Archived-At: <https://lists.01.org/hyperkitty/list/linux-nvdimm@lists.01.org/message/2G355OFILVBITKG7Z5SDUAX2HTUHO7AO/>
List-Archive: <https://lists.01.org/hyperkitty/list/linux-nvdimm@lists.01.org/>
List-Help: <mailto:linux-nvdimm-request@lists.01.org?subject=help>
List-Post: <mailto:linux-nvdimm@lists.01.org>
List-Subscribe: <mailto:linux-nvdimm-join@lists.01.org>
List-Unsubscribe: <mailto:linux-nvdimm-leave@lists.01.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Thu, Mar 18, 2021 at 3:02 AM Joao Martins <joao.m.martins@oracle.com> wrote:
>
> On 3/18/21 4:08 AM, Dan Williams wrote:
> > Now that device-dax and filesystem-dax are guaranteed to unmap all user
> > mappings of devmap / DAX pages before tearing down the 'struct page'
> > array, get_user_pages_fast() can rely on its traditional synchronization
> > method "validate_pte(); get_page(); revalidate_pte()" to catch races with
> > device shutdown. Specifically the unmap guarantee ensures that gup-fast
> > either succeeds in taking a page reference (lock-less), or it detects a
> > need to fall back to the slow path where the device presence can be
> > revalidated with locks held.
>
> [...]
>
> > @@ -2087,21 +2078,26 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
> >  #endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */
> >
> >  #if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
> > +
> >  static int __gup_device_huge(unsigned long pfn, unsigned long addr,
> >                            unsigned long end, unsigned int flags,
> >                            struct page **pages, int *nr)
> >  {
> >       int nr_start = *nr;
> > -     struct dev_pagemap *pgmap = NULL;
> >
> >       do {
> > -             struct page *page = pfn_to_page(pfn);
> > +             struct page *page;
> > +
> > +             /*
> > +              * Typically pfn_to_page() on a devmap pfn is not safe
> > +              * without holding a live reference on the hosting
> > +              * pgmap. In the gup-fast path it is safe because any
> > +              * races will be resolved by either gup-fast taking a
> > +              * reference or the shutdown path unmapping the pte to
> > +              * trigger gup-fast to fall back to the slow path.
> > +              */
> > +             page = pfn_to_page(pfn);
> >
> > -             pgmap = get_dev_pagemap(pfn, pgmap);
> > -             if (unlikely(!pgmap)) {
> > -                     undo_dev_pagemap(nr, nr_start, flags, pages);
> > -                     return 0;
> > -             }
> >               SetPageReferenced(page);
> >               pages[*nr] = page;
> >               if (unlikely(!try_grab_page(page, flags))) {
>
> So for allowing FOLL_LONGTERM[0] would it be OK if we used page->pgmap after
> try_grab_page() for checking pgmap type to see if we are in a device-dax
> longterm pin?
>

Yes. I still need to answer the question of whether mapping
invalidation triggers longterm pin holders to relinquish their hold,
but that's a problem regardless of whether gup-fast is supported or
not.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id B6477C433DB
	for <linux-kernel@archiver.kernel.org>; Thu, 18 Mar 2021 17:04:06 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 6D84164E05
	for <linux-kernel@archiver.kernel.org>; Thu, 18 Mar 2021 17:04:06 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S230338AbhCRRDe (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Thu, 18 Mar 2021 13:03:34 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59578 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S232220AbhCRRDN (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 18 Mar 2021 13:03:13 -0400
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 583B7C06175F
        for <linux-kernel@vger.kernel.org>; Thu, 18 Mar 2021 10:03:13 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id u4so7551368edv.9
        for <linux-kernel@vger.kernel.org>; Thu, 18 Mar 2021 10:03:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=intel-com.20150623.gappssmtp.com; s=20150623;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ncWZPnyeBiWOdZ1rqhn/kolCjnyW0fSBUFhdCHieBDM=;
        b=t7GWySP7B7GjasZeOxZIv+aUzBxCH4W8Be/Cy5Zw06Sb0yLfg7nYnjvi+LMPGBm+iy
         XU1pC+kO/ONtX1X5jRrh3oWqaYzP8VrOMDMSdbE3sEb/K2OPCuj32WF8LUbnS7WUUkER
         f/4lOy6HJMClpiu6qjhKKZtFhrjrVQKGnwMR9WtL5EBd/KCh9of1N1ll67hR0YZeKLV3
         KK/KNTdOTBqCM8AiipskMe6qhvDgT+aMxNjpBn2xW5c+VJQ6/8OIeFu7onCvsXGWhx2J
         VnXJ1RI+QZOWD8OVrk9m6l/pxM2WFTO5fyo5bQSttDcPLA4PDtmJKUqI3QzfSqUqh75G
         Wkuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ncWZPnyeBiWOdZ1rqhn/kolCjnyW0fSBUFhdCHieBDM=;
        b=X0Mrr7OoYzQZ3IIb3t2EcA2fjaW6a11dlo2gmfS4hkjQfQ8Wx3OfJ+H66FR1gQTlHy
         +oHl6iL1KhsIXYzkiWYCN8ghFblTVp/Bs4XaOCEqHt85tF+gbsETKQ42obnmaRTb8h8+
         XEA2QCdzN51gzJo7v2VZcNiwN4vs+7JmYxdzsTP7mOZL3YcwFzQaF4TACabwhGZfIuGe
         AtzUVUuswtTJUTs0kGXmSppYZu6I5QKJZAx6E01Nf/osSd6YADSIvmoxGWZoYucuuXXH
         VzQKdzgKAcwHM1dAZ2QyxRuGwe4HuRhPbEkyRtyZGZGvAtPjiOmKympWE+vKjouHXKl8
         jfwQ==
X-Gm-Message-State: AOAM532gohJOmH3pRS/ueh853XIKE5+PU+9fgZ5yaVlhr41jslA+seNB
        sSoVVi0h24zvpaSD745FxKMStJcKRgchdwOafHpwyA==
X-Google-Smtp-Source: ABdhPJxuNsdRluFA0/M5LLOxZ8cJZSLdLyy24eAaZULCocflm5Th9Ab5OwvvWKq3EP121Lq2ytUniLx2mfNJE2c/9s0=
X-Received: by 2002:a05:6402:1713:: with SMTP id y19mr3827680edu.52.1616086991914;
 Thu, 18 Mar 2021 10:03:11 -0700 (PDT)
MIME-Version: 1.0
References: <161604048257.1463742.1374527716381197629.stgit@dwillia2-desk3.amr.corp.intel.com>
 <161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com>
 <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com>
In-Reply-To: <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com>
From:   Dan Williams <dan.j.williams@intel.com>
Date:   Thu, 18 Mar 2021 10:03:06 -0700
Message-ID: <CAPcyv4g8=kGoQiY14CDEZryb-7T1_tePnC_-21w-wTfA7fQcDg@mail.gmail.com>
Subject: Re: [PATCH 3/3] mm/devmap: Remove pgmap accounting in the
 get_user_pages_fast() path
To:     Joao Martins <joao.m.martins@oracle.com>
Cc:     Jason Gunthorpe <jgg@ziepe.ca>, Christoph Hellwig <hch@lst.de>,
        Shiyang Ruan <ruansy.fnst@fujitsu.com>,
        Vishal Verma <vishal.l.verma@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Ira Weiny <ira.weiny@intel.com>,
        Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
        Andrew Morton <akpm@linux-foundation.org>,
        david <david@fromorbit.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux MM <linux-mm@kvack.org>,
        linux-nvdimm <linux-nvdimm@lists.01.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Mar 18, 2021 at 3:02 AM Joao Martins <joao.m.martins@oracle.com> wrote:
>
> On 3/18/21 4:08 AM, Dan Williams wrote:
> > Now that device-dax and filesystem-dax are guaranteed to unmap all user
> > mappings of devmap / DAX pages before tearing down the 'struct page'
> > array, get_user_pages_fast() can rely on its traditional synchronization
> > method "validate_pte(); get_page(); revalidate_pte()" to catch races with
> > device shutdown. Specifically the unmap guarantee ensures that gup-fast
> > either succeeds in taking a page reference (lock-less), or it detects a
> > need to fall back to the slow path where the device presence can be
> > revalidated with locks held.
>
> [...]
>
> > @@ -2087,21 +2078,26 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
> >  #endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */
> >
> >  #if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
> > +
> >  static int __gup_device_huge(unsigned long pfn, unsigned long addr,
> >                            unsigned long end, unsigned int flags,
> >                            struct page **pages, int *nr)
> >  {
> >       int nr_start = *nr;
> > -     struct dev_pagemap *pgmap = NULL;
> >
> >       do {
> > -             struct page *page = pfn_to_page(pfn);
> > +             struct page *page;
> > +
> > +             /*
> > +              * Typically pfn_to_page() on a devmap pfn is not safe
> > +              * without holding a live reference on the hosting
> > +              * pgmap. In the gup-fast path it is safe because any
> > +              * races will be resolved by either gup-fast taking a
> > +              * reference or the shutdown path unmapping the pte to
> > +              * trigger gup-fast to fall back to the slow path.
> > +              */
> > +             page = pfn_to_page(pfn);
> >
> > -             pgmap = get_dev_pagemap(pfn, pgmap);
> > -             if (unlikely(!pgmap)) {
> > -                     undo_dev_pagemap(nr, nr_start, flags, pages);
> > -                     return 0;
> > -             }
> >               SetPageReferenced(page);
> >               pages[*nr] = page;
> >               if (unlikely(!try_grab_page(page, flags))) {
>
> So for allowing FOLL_LONGTERM[0] would it be OK if we used page->pgmap after
> try_grab_page() for checking pgmap type to see if we are in a device-dax
> longterm pin?
>

Yes. I still need to answer the question of whether mapping
invalidation triggers longterm pin holders to relinquish their hold,
but that's a problem regardless of whether gup-fast is supported or
not.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=8ret=IQ=kvack.org=owner-linux-mm@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id A0D2CC433DB
	for <linux-mm@archiver.kernel.org>; Thu, 18 Mar 2021 17:10:20 +0000 (UTC)
Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17])
	by mail.kernel.org (Postfix) with ESMTP id 1588064F24
	for <linux-mm@archiver.kernel.org>; Thu, 18 Mar 2021 17:10:20 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1588064F24
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix)
	id 7589C8D0002; Thu, 18 Mar 2021 13:10:19 -0400 (EDT)
Received: by kanga.kvack.org (Postfix, from userid 40)
	id 72ECE6B0075; Thu, 18 Mar 2021 13:10:19 -0400 (EDT)
X-Delivered-To: int-list-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix, from userid 63042)
	id 5D0FD8D0002; Thu, 18 Mar 2021 13:10:19 -0400 (EDT)
X-Delivered-To: linux-mm@kvack.org
Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190])
	by kanga.kvack.org (Postfix) with ESMTP id 41D8F6B0074
	for <linux-mm@kvack.org>; Thu, 18 Mar 2021 13:10:19 -0400 (EDT)
Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251])
	by forelay02.hostedemail.com (Postfix) with ESMTP id E73D28154
	for <linux-mm@kvack.org>; Thu, 18 Mar 2021 17:10:18 +0000 (UTC)
X-FDA: 77933633316.09.6F39187
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41])
	by imf21.hostedemail.com (Postfix) with ESMTP id 869B1E005F0F
	for <linux-mm@kvack.org>; Thu, 18 Mar 2021 17:10:13 +0000 (UTC)
Received: by mail-ed1-f41.google.com with SMTP id bx7so7573498edb.12
        for <linux-mm@kvack.org>; Thu, 18 Mar 2021 10:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=intel-com.20150623.gappssmtp.com; s=20150623;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=ncWZPnyeBiWOdZ1rqhn/kolCjnyW0fSBUFhdCHieBDM=;
        b=t7GWySP7B7GjasZeOxZIv+aUzBxCH4W8Be/Cy5Zw06Sb0yLfg7nYnjvi+LMPGBm+iy
         XU1pC+kO/ONtX1X5jRrh3oWqaYzP8VrOMDMSdbE3sEb/K2OPCuj32WF8LUbnS7WUUkER
         f/4lOy6HJMClpiu6qjhKKZtFhrjrVQKGnwMR9WtL5EBd/KCh9of1N1ll67hR0YZeKLV3
         KK/KNTdOTBqCM8AiipskMe6qhvDgT+aMxNjpBn2xW5c+VJQ6/8OIeFu7onCvsXGWhx2J
         VnXJ1RI+QZOWD8OVrk9m6l/pxM2WFTO5fyo5bQSttDcPLA4PDtmJKUqI3QzfSqUqh75G
         Wkuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=ncWZPnyeBiWOdZ1rqhn/kolCjnyW0fSBUFhdCHieBDM=;
        b=C3emRnIgLcQbSIhqEBDInXd+HQnrMGA+UR+FWgj29FY80FmxBf8IgHVLDrUlFnirkN
         oOUlG4UXdM1dYoOgMH1m4S59eTq83L3t47kY/ddW24dlnBlhqS3a0+VxakCoW9ir8KTB
         6QXzzeD3Fs6OhFccujkAq8QcMg2COX+j66Hd8QST1shAwGfWScZIWUSHGTPJe40Qjw3a
         Q1sXObrHpZvW1l8Crb5nB3agVj70tT9N3hEsLS8JzaNI5cSaINf/ZliNdAZmIrwLcNDz
         +e9/CCo9IMQeao/voAZBeYQjR2t8KnDRkfWYwk2m8pMUs9W0TT55pveHWq42tO04FLcf
         uS/A==
X-Gm-Message-State: AOAM530rIKVI77cBvcROxbqnm49UCyTGeX6e2c0YUR3NfAiQzO5HGFhX
	W3JqoNpmo3hL4TZD5TeCj7AZ8JUFEGxik7nMruLjfJx1Dkk=
X-Google-Smtp-Source: ABdhPJxuNsdRluFA0/M5LLOxZ8cJZSLdLyy24eAaZULCocflm5Th9Ab5OwvvWKq3EP121Lq2ytUniLx2mfNJE2c/9s0=
X-Received: by 2002:a05:6402:1713:: with SMTP id y19mr3827680edu.52.1616086991914;
 Thu, 18 Mar 2021 10:03:11 -0700 (PDT)
MIME-Version: 1.0
References: <161604048257.1463742.1374527716381197629.stgit@dwillia2-desk3.amr.corp.intel.com>
 <161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com>
 <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com>
In-Reply-To: <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Thu, 18 Mar 2021 10:03:06 -0700
Message-ID: <CAPcyv4g8=kGoQiY14CDEZryb-7T1_tePnC_-21w-wTfA7fQcDg@mail.gmail.com>
Subject: Re: [PATCH 3/3] mm/devmap: Remove pgmap accounting in the
 get_user_pages_fast() path
To: Joao Martins <joao.m.martins@oracle.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Christoph Hellwig <hch@lst.de>, Shiyang Ruan <ruansy.fnst@fujitsu.com>, 
	Vishal Verma <vishal.l.verma@intel.com>, Dave Jiang <dave.jiang@intel.com>, 
	Ira Weiny <ira.weiny@intel.com>, Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>, 
	Andrew Morton <akpm@linux-foundation.org>, david <david@fromorbit.com>, 
	linux-fsdevel <linux-fsdevel@vger.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux MM <linux-mm@kvack.org>, 
	linux-nvdimm <linux-nvdimm@lists.01.org>
Content-Type: text/plain; charset="UTF-8"
X-Rspamd-Server: rspam04
X-Rspamd-Queue-Id: 869B1E005F0F
X-Stat-Signature: zmwuszsekzmyhce3uerosnibcqy397zp
Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from="<dan.j.williams@intel.com>"; helo=mail-ed1-f41.google.com; client-ip=209.85.208.41
X-HE-DKIM-Result: pass/pass
X-HE-Tag: 1616087413-176895
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: <linux-mm.kvack.org>

On Thu, Mar 18, 2021 at 3:02 AM Joao Martins <joao.m.martins@oracle.com> wrote:
>
> On 3/18/21 4:08 AM, Dan Williams wrote:
> > Now that device-dax and filesystem-dax are guaranteed to unmap all user
> > mappings of devmap / DAX pages before tearing down the 'struct page'
> > array, get_user_pages_fast() can rely on its traditional synchronization
> > method "validate_pte(); get_page(); revalidate_pte()" to catch races with
> > device shutdown. Specifically the unmap guarantee ensures that gup-fast
> > either succeeds in taking a page reference (lock-less), or it detects a
> > need to fall back to the slow path where the device presence can be
> > revalidated with locks held.
>
> [...]
>
> > @@ -2087,21 +2078,26 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
> >  #endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */
> >
> >  #if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
> > +
> >  static int __gup_device_huge(unsigned long pfn, unsigned long addr,
> >                            unsigned long end, unsigned int flags,
> >                            struct page **pages, int *nr)
> >  {
> >       int nr_start = *nr;
> > -     struct dev_pagemap *pgmap = NULL;
> >
> >       do {
> > -             struct page *page = pfn_to_page(pfn);
> > +             struct page *page;
> > +
> > +             /*
> > +              * Typically pfn_to_page() on a devmap pfn is not safe
> > +              * without holding a live reference on the hosting
> > +              * pgmap. In the gup-fast path it is safe because any
> > +              * races will be resolved by either gup-fast taking a
> > +              * reference or the shutdown path unmapping the pte to
> > +              * trigger gup-fast to fall back to the slow path.
> > +              */
> > +             page = pfn_to_page(pfn);
> >
> > -             pgmap = get_dev_pagemap(pfn, pgmap);
> > -             if (unlikely(!pgmap)) {
> > -                     undo_dev_pagemap(nr, nr_start, flags, pages);
> > -                     return 0;
> > -             }
> >               SetPageReferenced(page);
> >               pages[*nr] = page;
> >               if (unlikely(!try_grab_page(page, flags))) {
>
> So for allowing FOLL_LONGTERM[0] would it be OK if we used page->pgmap after
> try_grab_page() for checking pgmap type to see if we are in a device-dax
> longterm pin?
>

Yes. I still need to answer the question of whether mapping
invalidation triggers longterm pin holders to relinquish their hold,
but that's a problem regardless of whether gup-fast is supported or
not.