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 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 ; 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 ; 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 ; 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 ; 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 ; Thu, 18 Mar 2021 17:10:13 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id bx7so7573498edb.12 for ; 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 Date: Thu, 18 Mar 2021 10:03:06 -0700 Message-ID: Subject: Re: [PATCH 3/3] mm/devmap: Remove pgmap accounting in the get_user_pages_fast() path To: Joao Martins Cc: Jason Gunthorpe , Christoph Hellwig , Shiyang Ruan , Vishal Verma , Dave Jiang , Ira Weiny , Matthew Wilcox , Jan Kara , Andrew Morton , david , linux-fsdevel , Linux Kernel Mailing List , Linux MM , linux-nvdimm 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=""; 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: On Thu, Mar 18, 2021 at 3:02 AM Joao Martins 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.