From: Joao Martins <joao.m.martins@oracle.com> To: Dan Williams <dan.j.williams@intel.com> 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@fromorbit.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org Subject: Re: [PATCH 3/3] mm/devmap: Remove pgmap accounting in the get_user_pages_fast() path Date: Thu, 18 Mar 2021 10:00:54 +0000 [thread overview] Message-ID: <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com> (raw) In-Reply-To: <161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com> 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? Joao [0] https://lore.kernel.org/linux-mm/6a18179e-65f7-367d-89a9-d5162f10fef0@oracle.com/ _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Joao Martins <joao.m.martins@oracle.com> To: Dan Williams <dan.j.williams@intel.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@fromorbit.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org Subject: Re: [PATCH 3/3] mm/devmap: Remove pgmap accounting in the get_user_pages_fast() path Date: Thu, 18 Mar 2021 10:00:54 +0000 [thread overview] Message-ID: <66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com> (raw) In-Reply-To: <161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com> 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? Joao [0] https://lore.kernel.org/linux-mm/6a18179e-65f7-367d-89a9-d5162f10fef0@oracle.com/
next prev parent reply other threads:[~2021-03-18 10:01 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-18 4:08 [PATCH 0/3] mm, pmem: Force unmap pmem on surprise remove Dan Williams 2021-03-18 4:08 ` Dan Williams 2021-03-18 4:08 ` [PATCH 1/3] mm/memory-failure: Prepare for mass memory_failure() Dan Williams 2021-03-18 4:08 ` Dan Williams 2021-03-18 4:08 ` [PATCH 2/3] mm, dax, pmem: Introduce dev_pagemap_failure() Dan Williams 2021-03-18 4:08 ` Dan Williams 2021-03-18 4:45 ` Darrick J. Wong 2021-03-18 4:45 ` Darrick J. Wong 2021-03-18 19:26 ` Dan Williams 2021-03-18 19:26 ` Dan Williams 2021-03-18 19:26 ` Dan Williams 2021-03-18 4:57 ` Dave Chinner 2021-03-18 4:57 ` Dave Chinner 2021-03-18 19:20 ` Dan Williams 2021-03-18 19:20 ` Dan Williams 2021-03-18 19:20 ` Dan Williams 2021-03-20 1:46 ` Dave Chinner 2021-03-20 1:46 ` Dave Chinner 2021-03-20 2:39 ` Dan Williams 2021-03-20 2:39 ` Dan Williams 2021-03-20 2:39 ` Dan Williams 2021-03-18 4:08 ` [PATCH 3/3] mm/devmap: Remove pgmap accounting in the get_user_pages_fast() path Dan Williams 2021-03-18 4:08 ` Dan Williams 2021-03-18 10:00 ` Joao Martins [this message] 2021-03-18 10:00 ` Joao Martins 2021-03-18 17:03 ` Dan Williams 2021-03-18 17:03 ` Dan Williams 2021-03-18 17:03 ` Dan Williams 2021-03-25 14:34 ` Jason Gunthorpe 2021-03-29 23:24 ` Dan Williams 2021-03-29 23:24 ` Dan Williams 2021-03-29 23:24 ` Dan Williams 2021-03-30 13:49 ` Jason Gunthorpe 2021-03-24 17:45 ` Dan Williams 2021-03-24 17:45 ` Dan Williams 2021-03-24 17:45 ` Dan Williams 2021-03-24 19:00 ` Joao Martins 2021-03-24 19:00 ` Joao Martins 2021-04-01 19:54 ` Joao Martins 2021-04-01 19:54 ` Joao Martins 2021-03-25 14:37 ` Jason Gunthorpe 2021-03-25 13:02 ` [PATCH 0/3] mm, pmem: Force unmap pmem on surprise remove David Hildenbrand 2021-03-25 13:02 ` David Hildenbrand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=66514812-6a24-8e2e-7be5-c61e188fecc4@oracle.com \ --to=joao.m.martins@oracle.com \ --cc=akpm@linux-foundation.org \ --cc=dan.j.williams@intel.com \ --cc=david@fromorbit.com \ --cc=hch@lst.de \ --cc=jack@suse.cz \ --cc=jgg@ziepe.ca \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@lists.01.org \ --cc=ruansy.fnst@fujitsu.com \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.