[PATCH v3 0/4] Devmap cleanups + arm64 support

[PATCH v3 0/4] Devmap cleanups + arm64 support

[Robin Murphy]

Hi all,

Here's a refresh of my devmap stuff, now including the end goal as
well. Patches #1 to #3 are just a rebase of v2, and I hope are ready to
be picked up in the mm tree (#1 is currently doing double-duty in Dan's
subsection series as well). Patch #4 could either go via mm if Will and
Catalin agree, or could go via arm64 with a small tweak to let it build
(but otherwise do nothing) until it meets up with #3 again.

Robin.


Robin Murphy (4):
  mm/memremap: Rename and consolidate SECTION_SIZE
  mm: clean up is_device_*_page() definitions
  mm: introduce ARCH_HAS_PTE_DEVMAP
  arm64: mm: Implement pte_devmap support

 arch/arm64/Kconfig                           |  1 +
 arch/arm64/include/asm/pgtable-prot.h        |  1 +
 arch/arm64/include/asm/pgtable.h             | 19 ++++++++
 arch/powerpc/Kconfig                         |  2 +-
 arch/powerpc/include/asm/book3s/64/pgtable.h |  1 -
 arch/x86/Kconfig                             |  2 +-
 arch/x86/include/asm/pgtable.h               |  4 +-
 arch/x86/include/asm/pgtable_types.h         |  1 -
 include/linux/mm.h                           | 47 +++++++-------------
 include/linux/mmzone.h                       |  1 +
 include/linux/pfn_t.h                        |  4 +-
 kernel/memremap.c                            | 10 ++---
 mm/Kconfig                                   |  5 +--
 mm/gup.c                                     |  2 +-
 mm/hmm.c                                     |  2 -
 15 files changed, 50 insertions(+), 52 deletions(-)

-- 
2.21.0.dirty

[PATCH v3 1/4] mm/memremap: Rename and consolidate SECTION_SIZE

[Robin Murphy]

Trying to activate ZONE_DEVICE for arm64 reveals that memremap's
internal helpers for sparsemem sections conflict with and arm64's
definitions for hugepages, which inherit the name of "sections" from
earlier versions of the ARM architecture.

Disambiguate memremap (and now HMM too) by propagating sparsemem's PA_
prefix, to clarify that these values are in terms of addresses rather
than PFNs (and because it's a heck of a lot easier than changing all the
arch code). SECTION_MASK is unused, so it can just go.

[anshuman: Consolidated mm/hmm.c instance and updated the commit message]

Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
 include/linux/mmzone.h |  1 +
 kernel/memremap.c      | 10 ++++------
 mm/hmm.c               |  2 --
 3 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 70394cabaf4e..427b79c39b3c 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1134,6 +1134,7 @@ static inline unsigned long early_pfn_to_nid(unsigned long pfn)
  * PFN_SECTION_SHIFT		pfn to/from section number
  */
 #define PA_SECTION_SHIFT	(SECTION_SIZE_BITS)
+#define PA_SECTION_SIZE		(1UL << PA_SECTION_SHIFT)
 #define PFN_SECTION_SHIFT	(SECTION_SIZE_BITS - PAGE_SHIFT)
 
 #define NR_MEM_SECTIONS		(1UL << SECTIONS_SHIFT)
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 1490e63f69a9..b8c8010e87e0 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -14,8 +14,6 @@
 #include <linux/hmm.h>
 
 static DEFINE_XARRAY(pgmap_array);
-#define SECTION_MASK ~((1UL << PA_SECTION_SHIFT) - 1)
-#define SECTION_SIZE (1UL << PA_SECTION_SHIFT)
 
 #if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
 vm_fault_t device_private_entry_fault(struct vm_area_struct *vma,
@@ -97,8 +95,8 @@ static void devm_memremap_pages_release(void *data)
 		put_page(pfn_to_page(pfn));
 
 	/* pages are dead and unused, undo the arch mapping */
-	align_start = res->start & ~(SECTION_SIZE - 1);
-	align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
+	align_start = res->start & ~(PA_SECTION_SIZE - 1);
+	align_size = ALIGN(res->start + resource_size(res), PA_SECTION_SIZE)
 		- align_start;
 
 	nid = page_to_nid(pfn_to_page(align_start >> PAGE_SHIFT));
@@ -159,8 +157,8 @@ void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap)
 	if (!pgmap->ref || !pgmap->kill)
 		return ERR_PTR(-EINVAL);
 
-	align_start = res->start & ~(SECTION_SIZE - 1);
-	align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
+	align_start = res->start & ~(PA_SECTION_SIZE - 1);
+	align_size = ALIGN(res->start + resource_size(res), PA_SECTION_SIZE)
 		- align_start;
 	align_end = align_start + align_size - 1;
 
diff --git a/mm/hmm.c b/mm/hmm.c
index 0db8491090b8..a7e7f8e33c5f 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -34,8 +34,6 @@
 #include <linux/mmu_notifier.h>
 #include <linux/memory_hotplug.h>
 
-#define PA_SECTION_SIZE (1UL << PA_SECTION_SHIFT)
-
 #if IS_ENABLED(CONFIG_HMM_MIRROR)
 static const struct mmu_notifier_ops hmm_mmu_notifier_ops;
 
-- 
2.21.0.dirty

[PATCH v3 2/4] mm: clean up is_device_*_page() definitions

[Robin Murphy]

Refactor is_device_{public,private}_page() with is_pci_p2pdma_page()
to make them all consistent in depending on their respective config
options even when CONFIG_DEV_PAGEMAP_OPS is enabled for other reasons.
This allows a little more compile-time optimisation as well as the
conceptual and cosmetic cleanup.

Suggested-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 include/linux/mm.h | 43 +++++++++++++------------------------------
 1 file changed, 13 insertions(+), 30 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0e8834ac32b7..9cd613a7f67b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -942,32 +942,6 @@ static inline bool put_devmap_managed_page(struct page *page)
 	}
 	return false;
 }
-
-static inline bool is_device_private_page(const struct page *page)
-{
-	return is_zone_device_page(page) &&
-		page->pgmap->type == MEMORY_DEVICE_PRIVATE;
-}
-
-static inline bool is_device_public_page(const struct page *page)
-{
-	return is_zone_device_page(page) &&
-		page->pgmap->type == MEMORY_DEVICE_PUBLIC;
-}
-
-#ifdef CONFIG_PCI_P2PDMA
-static inline bool is_pci_p2pdma_page(const struct page *page)
-{
-	return is_zone_device_page(page) &&
-		page->pgmap->type == MEMORY_DEVICE_PCI_P2PDMA;
-}
-#else /* CONFIG_PCI_P2PDMA */
-static inline bool is_pci_p2pdma_page(const struct page *page)
-{
-	return false;
-}
-#endif /* CONFIG_PCI_P2PDMA */
-
 #else /* CONFIG_DEV_PAGEMAP_OPS */
 static inline void dev_pagemap_get_ops(void)
 {
@@ -981,22 +955,31 @@ static inline bool put_devmap_managed_page(struct page *page)
 {
 	return false;
 }
+#endif /* CONFIG_DEV_PAGEMAP_OPS */
 
 static inline bool is_device_private_page(const struct page *page)
 {
-	return false;
+	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
+		IS_ENABLED(CONFIG_DEVICE_PRIVATE) &&
+		is_zone_device_page(page) &&
+		page->pgmap->type == MEMORY_DEVICE_PRIVATE;
 }
 
 static inline bool is_device_public_page(const struct page *page)
 {
-	return false;
+	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
+		IS_ENABLED(CONFIG_DEVICE_PUBLIC) &&
+		is_zone_device_page(page) &&
+		page->pgmap->type == MEMORY_DEVICE_PUBLIC;
 }
 
 static inline bool is_pci_p2pdma_page(const struct page *page)
 {
-	return false;
+	return IS_ENABLED(CONFIG_DEV_PAGEMAP_OPS) &&
+		IS_ENABLED(CONFIG_PCI_P2PDMA) &&
+		is_zone_device_page(page) &&
+		page->pgmap->type == MEMORY_DEVICE_PCI_P2PDMA;
 }
-#endif /* CONFIG_DEV_PAGEMAP_OPS */
 
 /* 127: arbitrary random number, small enough to assemble well */
 #define page_ref_zero_or_close_to_overflow(page) \
-- 
2.21.0.dirty

[PATCH v3 3/4] mm: introduce ARCH_HAS_PTE_DEVMAP

[Robin Murphy]

ARCH_HAS_ZONE_DEVICE is somewhat meaningless in itself, and combined
with the long-out-of-date comment can lead to the impression than an
architecture may just enable it (since __add_pages() now "comprehends
device memory" for itself) and expect things to work.

In practice, however, ZONE_DEVICE users have little chance of
functioning correctly without __HAVE_ARCH_PTE_DEVMAP, so let's clean
that up the same way as ARCH_HAS_PTE_SPECIAL and make it the proper
dependency so the real situation is clearer.

Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Acked-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 arch/powerpc/Kconfig                         | 2 +-
 arch/powerpc/include/asm/book3s/64/pgtable.h | 1 -
 arch/x86/Kconfig                             | 2 +-
 arch/x86/include/asm/pgtable.h               | 4 ++--
 arch/x86/include/asm/pgtable_types.h         | 1 -
 include/linux/mm.h                           | 4 ++--
 include/linux/pfn_t.h                        | 4 ++--
 mm/Kconfig                                   | 5 ++---
 mm/gup.c                                     | 2 +-
 9 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308c8..1120ff8ac715 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -128,6 +128,7 @@ config PPC
 	select ARCH_HAS_MMIOWB			if PPC64
 	select ARCH_HAS_PHYS_TO_DMA
 	select ARCH_HAS_PMEM_API                if PPC64
+	select ARCH_HAS_PTE_DEVMAP		if PPC_BOOK3S_64
 	select ARCH_HAS_PTE_SPECIAL
 	select ARCH_HAS_MEMBARRIER_CALLBACKS
 	select ARCH_HAS_SCALED_CPUTIME		if VIRT_CPU_ACCOUNTING_NATIVE && PPC64
@@ -135,7 +136,6 @@ config PPC
 	select ARCH_HAS_TICK_BROADCAST		if GENERIC_CLOCKEVENTS_BROADCAST
 	select ARCH_HAS_UACCESS_FLUSHCACHE	if PPC64
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
-	select ARCH_HAS_ZONE_DEVICE		if PPC_BOOK3S_64
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
 	select ARCH_KEEP_MEMBLOCK
 	select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 7dede2e34b70..c6c2bdfb369b 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -90,7 +90,6 @@
 #define _PAGE_SOFT_DIRTY	_RPAGE_SW3 /* software: software dirty tracking */
 #define _PAGE_SPECIAL		_RPAGE_SW2 /* software: special page */
 #define _PAGE_DEVMAP		_RPAGE_SW1 /* software: ZONE_DEVICE page */
-#define __HAVE_ARCH_PTE_DEVMAP
 
 /*
  * Drivers request for cache inhibited pte mapping using _PAGE_NO_CACHE
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2bbbd4d1ba31..57c4e80bd368 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -69,6 +69,7 @@ config X86
 	select ARCH_HAS_KCOV			if X86_64
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
 	select ARCH_HAS_PMEM_API		if X86_64
+	select ARCH_HAS_PTE_DEVMAP		if X86_64
 	select ARCH_HAS_PTE_SPECIAL
 	select ARCH_HAS_REFCOUNT
 	select ARCH_HAS_UACCESS_FLUSHCACHE	if X86_64
@@ -79,7 +80,6 @@ config X86
 	select ARCH_HAS_STRICT_MODULE_RWX
 	select ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
-	select ARCH_HAS_ZONE_DEVICE		if X86_64
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG
 	select ARCH_MIGHT_HAVE_ACPI_PDC		if ACPI
 	select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 5e0509b41986..0bc530c4eb13 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -271,7 +271,7 @@ static inline int has_transparent_hugepage(void)
 	return boot_cpu_has(X86_FEATURE_PSE);
 }
 
-#ifdef __HAVE_ARCH_PTE_DEVMAP
+#ifdef CONFIG_ARCH_HAS_PTE_DEVMAP
 static inline int pmd_devmap(pmd_t pmd)
 {
 	return !!(pmd_val(pmd) & _PAGE_DEVMAP);
@@ -732,7 +732,7 @@ static inline int pte_present(pte_t a)
 	return pte_flags(a) & (_PAGE_PRESENT | _PAGE_PROTNONE);
 }
 
-#ifdef __HAVE_ARCH_PTE_DEVMAP
+#ifdef CONFIG_ARCH_HAS_PTE_DEVMAP
 static inline int pte_devmap(pte_t a)
 {
 	return (pte_flags(a) & _PAGE_DEVMAP) == _PAGE_DEVMAP;
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index d6ff0bbdb394..b5e49e6bac63 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -103,7 +103,6 @@
 #if defined(CONFIG_X86_64) || defined(CONFIG_X86_PAE)
 #define _PAGE_NX	(_AT(pteval_t, 1) << _PAGE_BIT_NX)
 #define _PAGE_DEVMAP	(_AT(u64, 1) << _PAGE_BIT_DEVMAP)
-#define __HAVE_ARCH_PTE_DEVMAP
 #else
 #define _PAGE_NX	(_AT(pteval_t, 0))
 #define _PAGE_DEVMAP	(_AT(pteval_t, 0))
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 9cd613a7f67b..f61c016de005 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -536,7 +536,7 @@ static inline void vma_set_anonymous(struct vm_area_struct *vma)
 struct mmu_gather;
 struct inode;
 
-#if !defined(__HAVE_ARCH_PTE_DEVMAP) || !defined(CONFIG_TRANSPARENT_HUGEPAGE)
+#if !defined(CONFIG_ARCH_HAS_PTE_DEVMAP) || !defined(CONFIG_TRANSPARENT_HUGEPAGE)
 static inline int pmd_devmap(pmd_t pmd)
 {
 	return 0;
@@ -1754,7 +1754,7 @@ static inline void sync_mm_rss(struct mm_struct *mm)
 }
 #endif
 
-#ifndef __HAVE_ARCH_PTE_DEVMAP
+#ifndef CONFIG_ARCH_HAS_PTE_DEVMAP
 static inline int pte_devmap(pte_t pte)
 {
 	return 0;
diff --git a/include/linux/pfn_t.h b/include/linux/pfn_t.h
index 7bb77850c65a..de8bc66b10a4 100644
--- a/include/linux/pfn_t.h
+++ b/include/linux/pfn_t.h
@@ -104,7 +104,7 @@ static inline pud_t pfn_t_pud(pfn_t pfn, pgprot_t pgprot)
 #endif
 #endif
 
-#ifdef __HAVE_ARCH_PTE_DEVMAP
+#ifdef CONFIG_ARCH_HAS_PTE_DEVMAP
 static inline bool pfn_t_devmap(pfn_t pfn)
 {
 	const u64 flags = PFN_DEV|PFN_MAP;
@@ -122,7 +122,7 @@ pmd_t pmd_mkdevmap(pmd_t pmd);
 	defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
 pud_t pud_mkdevmap(pud_t pud);
 #endif
-#endif /* __HAVE_ARCH_PTE_DEVMAP */
+#endif /* CONFIG_ARCH_HAS_PTE_DEVMAP */
 
 #ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
 static inline bool pfn_t_special(pfn_t pfn)
diff --git a/mm/Kconfig b/mm/Kconfig
index ee8d1f311858..3aeef0442d03 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -647,8 +647,7 @@ config IDLE_PAGE_TRACKING
 	  See Documentation/admin-guide/mm/idle_page_tracking.rst for
 	  more details.
 
-# arch_add_memory() comprehends device memory
-config ARCH_HAS_ZONE_DEVICE
+config ARCH_HAS_PTE_DEVMAP
 	bool
 
 config ZONE_DEVICE
@@ -656,7 +655,7 @@ config ZONE_DEVICE
 	depends on MEMORY_HOTPLUG
 	depends on MEMORY_HOTREMOVE
 	depends on SPARSEMEM_VMEMMAP
-	depends on ARCH_HAS_ZONE_DEVICE
+	depends on ARCH_HAS_PTE_DEVMAP
 	select XARRAY_MULTI
 
 	help
diff --git a/mm/gup.c b/mm/gup.c
index 2c08248d4fa2..777010ca3bf0 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1799,7 +1799,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
 }
 #endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */
 
-#if defined(__HAVE_ARCH_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
+#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, struct page **pages, int *nr)
 {
-- 
2.21.0.dirty

[PATCH v3 4/4] arm64: mm: Implement pte_devmap support

[Robin Murphy]

In order for things like get_user_pages() to work on ZONE_DEVICE memory,
we need a software PTE bit to identify device-backed PFNs. Hook this up
along with the relevant helpers to join in with ARCH_HAS_PTE_DEVMAP.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 arch/arm64/Kconfig                    |  1 +
 arch/arm64/include/asm/pgtable-prot.h |  1 +
 arch/arm64/include/asm/pgtable.h      | 19 +++++++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4780eb7af842..b5a4611fa4c6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -23,6 +23,7 @@ config ARM64
 	select ARCH_HAS_KCOV
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
+	select ARCH_HAS_PTE_DEVMAP
 	select ARCH_HAS_PTE_SPECIAL
 	select ARCH_HAS_SETUP_DMA_OPS
 	select ARCH_HAS_SET_MEMORY
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 986e41c4c32b..af0b372d15e5 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -28,6 +28,7 @@
 #define PTE_WRITE		(PTE_DBM)		 /* same as DBM (51) */
 #define PTE_DIRTY		(_AT(pteval_t, 1) << 55)
 #define PTE_SPECIAL		(_AT(pteval_t, 1) << 56)
+#define PTE_DEVMAP		(_AT(pteval_t, 1) << 57)
 #define PTE_PROT_NONE		(_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
 
 #ifndef __ASSEMBLY__
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 2c41b04708fe..a6378625d47c 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -90,6 +90,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 #define pte_write(pte)		(!!(pte_val(pte) & PTE_WRITE))
 #define pte_user_exec(pte)	(!(pte_val(pte) & PTE_UXN))
 #define pte_cont(pte)		(!!(pte_val(pte) & PTE_CONT))
+#define pte_devmap(pte)		(!!(pte_val(pte) & PTE_DEVMAP))
 
 #define pte_cont_addr_end(addr, end)						\
 ({	unsigned long __boundary = ((addr) + CONT_PTE_SIZE) & CONT_PTE_MASK;	\
@@ -217,6 +218,11 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
 	return __pmd(pmd_val(pmd) | PMD_SECT_CONT);
 }
 
+static inline pte_t pte_mkdevmap(pte_t pte)
+{
+	return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
+}
+
 static inline void set_pte(pte_t *ptep, pte_t pte)
 {
 	WRITE_ONCE(*ptep, pte);
@@ -381,6 +387,9 @@ static inline int pmd_protnone(pmd_t pmd)
 
 #define pmd_mkhuge(pmd)		(__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
 
+#define pmd_devmap(pmd)		pte_devmap(pmd_pte(pmd))
+#define pmd_mkdevmap(pmd)	pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
+
 #define __pmd_to_phys(pmd)	__pte_to_phys(pmd_pte(pmd))
 #define __phys_to_pmd_val(phys)	__phys_to_pte_val(phys)
 #define pmd_pfn(pmd)		((__pmd_to_phys(pmd) & PMD_MASK) >> PAGE_SHIFT)
@@ -537,6 +546,11 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
 	return __pud_to_phys(pud);
 }
 
+static inline int pud_devmap(pud_t pud)
+{
+	return 0;
+}
+
 /* Find an entry in the second-level page table. */
 #define pmd_index(addr)		(((addr) >> PMD_SHIFT) & (PTRS_PER_PMD - 1))
 
@@ -624,6 +638,11 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
 
 #define pgd_ERROR(pgd)		__pgd_error(__FILE__, __LINE__, pgd_val(pgd))
 
+static inline int pgd_devmap(pgd_t pgd)
+{
+	return 0;
+}
+
 /* to find an entry in a page-table-directory */
 #define pgd_index(addr)		(((addr) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1))
 
-- 
2.21.0.dirty

Re: [PATCH v3 4/4] arm64: mm: Implement pte_devmap support

[Will Deacon]

On Thu, May 23, 2019 at 04:03:16PM +0100, Robin Murphy wrote:
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 2c41b04708fe..a6378625d47c 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -90,6 +90,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
>  #define pte_write(pte)		(!!(pte_val(pte) & PTE_WRITE))
>  #define pte_user_exec(pte)	(!(pte_val(pte) & PTE_UXN))
>  #define pte_cont(pte)		(!!(pte_val(pte) & PTE_CONT))
> +#define pte_devmap(pte)		(!!(pte_val(pte) & PTE_DEVMAP))
>  
>  #define pte_cont_addr_end(addr, end)						\
>  ({	unsigned long __boundary = ((addr) + CONT_PTE_SIZE) & CONT_PTE_MASK;	\
> @@ -217,6 +218,11 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
>  	return __pmd(pmd_val(pmd) | PMD_SECT_CONT);
>  }
>  
> +static inline pte_t pte_mkdevmap(pte_t pte)
> +{
> +	return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
> +}
> +
>  static inline void set_pte(pte_t *ptep, pte_t pte)
>  {
>  	WRITE_ONCE(*ptep, pte);
> @@ -381,6 +387,9 @@ static inline int pmd_protnone(pmd_t pmd)
>  
>  #define pmd_mkhuge(pmd)		(__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
>  
> +#define pmd_devmap(pmd)		pte_devmap(pmd_pte(pmd))
> +#define pmd_mkdevmap(pmd)	pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
> +
>  #define __pmd_to_phys(pmd)	__pte_to_phys(pmd_pte(pmd))
>  #define __phys_to_pmd_val(phys)	__phys_to_pte_val(phys)
>  #define pmd_pfn(pmd)		((__pmd_to_phys(pmd) & PMD_MASK) >> PAGE_SHIFT)
> @@ -537,6 +546,11 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
>  	return __pud_to_phys(pud);
>  }
>  
> +static inline int pud_devmap(pud_t pud)
> +{
> +	return 0;
> +}
> +
>  /* Find an entry in the second-level page table. */
>  #define pmd_index(addr)		(((addr) >> PMD_SHIFT) & (PTRS_PER_PMD - 1))
>  
> @@ -624,6 +638,11 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
>  
>  #define pgd_ERROR(pgd)		__pgd_error(__FILE__, __LINE__, pgd_val(pgd))
>  
> +static inline int pgd_devmap(pgd_t pgd)
> +{
> +	return 0;
> +}

I think you need to guard this and pXd_devmap() with
CONFIG_TRANSPARENT_HUGEPAGE, otherwise you'll conflict with the dummy
definitions in mm.h and the build will fail.

Will

Re: [PATCH v3 4/4] arm64: mm: Implement pte_devmap support

[Robin Murphy]

On 24/05/2019 19:08, Will Deacon wrote:
> On Thu, May 23, 2019 at 04:03:16PM +0100, Robin Murphy wrote:
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 2c41b04708fe..a6378625d47c 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -90,6 +90,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
>>   #define pte_write(pte)		(!!(pte_val(pte) & PTE_WRITE))
>>   #define pte_user_exec(pte)	(!(pte_val(pte) & PTE_UXN))
>>   #define pte_cont(pte)		(!!(pte_val(pte) & PTE_CONT))
>> +#define pte_devmap(pte)		(!!(pte_val(pte) & PTE_DEVMAP))
>>   
>>   #define pte_cont_addr_end(addr, end)						\
>>   ({	unsigned long __boundary = ((addr) + CONT_PTE_SIZE) & CONT_PTE_MASK;	\
>> @@ -217,6 +218,11 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
>>   	return __pmd(pmd_val(pmd) | PMD_SECT_CONT);
>>   }
>>   
>> +static inline pte_t pte_mkdevmap(pte_t pte)
>> +{
>> +	return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
>> +}
>> +
>>   static inline void set_pte(pte_t *ptep, pte_t pte)
>>   {
>>   	WRITE_ONCE(*ptep, pte);
>> @@ -381,6 +387,9 @@ static inline int pmd_protnone(pmd_t pmd)
>>   
>>   #define pmd_mkhuge(pmd)		(__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
>>   
>> +#define pmd_devmap(pmd)		pte_devmap(pmd_pte(pmd))
>> +#define pmd_mkdevmap(pmd)	pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
>> +
>>   #define __pmd_to_phys(pmd)	__pte_to_phys(pmd_pte(pmd))
>>   #define __phys_to_pmd_val(phys)	__phys_to_pte_val(phys)
>>   #define pmd_pfn(pmd)		((__pmd_to_phys(pmd) & PMD_MASK) >> PAGE_SHIFT)
>> @@ -537,6 +546,11 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
>>   	return __pud_to_phys(pud);
>>   }
>>   
>> +static inline int pud_devmap(pud_t pud)
>> +{
>> +	return 0;
>> +}
>> +
>>   /* Find an entry in the second-level page table. */
>>   #define pmd_index(addr)		(((addr) >> PMD_SHIFT) & (PTRS_PER_PMD - 1))
>>   
>> @@ -624,6 +638,11 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
>>   
>>   #define pgd_ERROR(pgd)		__pgd_error(__FILE__, __LINE__, pgd_val(pgd))
>>   
>> +static inline int pgd_devmap(pgd_t pgd)
>> +{
>> +	return 0;
>> +}
> 
> I think you need to guard this and pXd_devmap() with
> CONFIG_TRANSPARENT_HUGEPAGE, otherwise you'll conflict with the dummy
> definitions in mm.h and the build will fail.

Ah, right you are - I got as far as catching similar issues with 
CONFIG_PGTABLE_LEVELS, but apparently I failed to spot the !THP guards 
in x86 and powerpc. Let me give this one a tweak and test a wider range 
of configs...

Robin.

Re: [PATCH v3 4/4] arm64: mm: Implement pte_devmap support

[Anshuman Khandual]

On 05/24/2019 11:38 PM, Will Deacon wrote:
> On Thu, May 23, 2019 at 04:03:16PM +0100, Robin Murphy wrote:
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 2c41b04708fe..a6378625d47c 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -90,6 +90,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
>>  #define pte_write(pte)		(!!(pte_val(pte) & PTE_WRITE))
>>  #define pte_user_exec(pte)	(!(pte_val(pte) & PTE_UXN))
>>  #define pte_cont(pte)		(!!(pte_val(pte) & PTE_CONT))
>> +#define pte_devmap(pte)		(!!(pte_val(pte) & PTE_DEVMAP))
>>  
>>  #define pte_cont_addr_end(addr, end)						\
>>  ({	unsigned long __boundary = ((addr) + CONT_PTE_SIZE) & CONT_PTE_MASK;	\
>> @@ -217,6 +218,11 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
>>  	return __pmd(pmd_val(pmd) | PMD_SECT_CONT);
>>  }
>>  
>> +static inline pte_t pte_mkdevmap(pte_t pte)
>> +{
>> +	return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
>> +}
>> +
>>  static inline void set_pte(pte_t *ptep, pte_t pte)
>>  {
>>  	WRITE_ONCE(*ptep, pte);
>> @@ -381,6 +387,9 @@ static inline int pmd_protnone(pmd_t pmd)
>>  
>>  #define pmd_mkhuge(pmd)		(__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
>>  
>> +#define pmd_devmap(pmd)		pte_devmap(pmd_pte(pmd))
>> +#define pmd_mkdevmap(pmd)	pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
>> +
>>  #define __pmd_to_phys(pmd)	__pte_to_phys(pmd_pte(pmd))
>>  #define __phys_to_pmd_val(phys)	__phys_to_pte_val(phys)
>>  #define pmd_pfn(pmd)		((__pmd_to_phys(pmd) & PMD_MASK) >> PAGE_SHIFT)
>> @@ -537,6 +546,11 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
>>  	return __pud_to_phys(pud);
>>  }
>>  
>> +static inline int pud_devmap(pud_t pud)
>> +{
>> +	return 0;
>> +}
>> +
>>  /* Find an entry in the second-level page table. */
>>  #define pmd_index(addr)		(((addr) >> PMD_SHIFT) & (PTRS_PER_PMD - 1))
>>  
>> @@ -624,6 +638,11 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
>>  
>>  #define pgd_ERROR(pgd)		__pgd_error(__FILE__, __LINE__, pgd_val(pgd))
>>  
>> +static inline int pgd_devmap(pgd_t pgd)
>> +{
>> +	return 0;
>> +}
> 
> I think you need to guard this and pXd_devmap() with
> CONFIG_TRANSPARENT_HUGEPAGE, otherwise you'll conflict with the dummy
> definitions in mm.h and the build will fail.

Just curious why pgd_devmap() also needs to be wrapped in TRANSPARENT_HUGEPAGE
config (or use this dummy otherwise). IIUC in case of DAX mappings there can
never be a huge mapping at PGD level. It only supports PMD or PUD based ones.

[PATCH v3.1 4/4] arm64: mm: Implement pte_devmap support

[Robin Murphy]

In order for things like get_user_pages() to work on ZONE_DEVICE memory,
we need a software PTE bit to identify device-backed PFNs. Hook this up
along with the relevant helpers to join in with ARCH_HAS_PTE_DEVMAP.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

Fix to build correctly under all combinations of
CONFIG_PGTABLE_LEVELS and CONFIG_TRANSPARENT_HUGEPAGE.

 arch/arm64/Kconfig                    |  1 +
 arch/arm64/include/asm/pgtable-prot.h |  1 +
 arch/arm64/include/asm/pgtable.h      | 21 +++++++++++++++++++++
 3 files changed, 23 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4780eb7af842..b5a4611fa4c6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -23,6 +23,7 @@ config ARM64
 	select ARCH_HAS_KCOV
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_MEMBARRIER_SYNC_CORE
+	select ARCH_HAS_PTE_DEVMAP
 	select ARCH_HAS_PTE_SPECIAL
 	select ARCH_HAS_SETUP_DMA_OPS
 	select ARCH_HAS_SET_MEMORY
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 986e41c4c32b..af0b372d15e5 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -28,6 +28,7 @@
 #define PTE_WRITE		(PTE_DBM)		 /* same as DBM (51) */
 #define PTE_DIRTY		(_AT(pteval_t, 1) << 55)
 #define PTE_SPECIAL		(_AT(pteval_t, 1) << 56)
+#define PTE_DEVMAP		(_AT(pteval_t, 1) << 57)
 #define PTE_PROT_NONE		(_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
 
 #ifndef __ASSEMBLY__
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 2c41b04708fe..7a2cf6939311 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -90,6 +90,7 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
 #define pte_write(pte)		(!!(pte_val(pte) & PTE_WRITE))
 #define pte_user_exec(pte)	(!(pte_val(pte) & PTE_UXN))
 #define pte_cont(pte)		(!!(pte_val(pte) & PTE_CONT))
+#define pte_devmap(pte)		(!!(pte_val(pte) & PTE_DEVMAP))
 
 #define pte_cont_addr_end(addr, end)						\
 ({	unsigned long __boundary = ((addr) + CONT_PTE_SIZE) & CONT_PTE_MASK;	\
@@ -217,6 +218,11 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
 	return __pmd(pmd_val(pmd) | PMD_SECT_CONT);
 }
 
+static inline pte_t pte_mkdevmap(pte_t pte)
+{
+	return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
+}
+
 static inline void set_pte(pte_t *ptep, pte_t pte)
 {
 	WRITE_ONCE(*ptep, pte);
@@ -381,6 +387,11 @@ static inline int pmd_protnone(pmd_t pmd)
 
 #define pmd_mkhuge(pmd)		(__pmd(pmd_val(pmd) & ~PMD_TABLE_BIT))
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define pmd_devmap(pmd)		pte_devmap(pmd_pte(pmd))
+#endif
+#define pmd_mkdevmap(pmd)	pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
+
 #define __pmd_to_phys(pmd)	__pte_to_phys(pmd_pte(pmd))
 #define __phys_to_pmd_val(phys)	__phys_to_pte_val(phys)
 #define pmd_pfn(pmd)		((__pmd_to_phys(pmd) & PMD_MASK) >> PAGE_SHIFT)
@@ -666,6 +677,16 @@ static inline int pmdp_set_access_flags(struct vm_area_struct *vma,
 {
 	return ptep_set_access_flags(vma, address, (pte_t *)pmdp, pmd_pte(entry), dirty);
 }
+
+static inline int pud_devmap(pud_t pud)
+{
+	return 0;
+}
+
+static inline int pgd_devmap(pgd_t pgd)
+{
+	return 0;
+}
 #endif
 
 /*
-- 
2.21.0.dirty

Re: [PATCH v3.1 4/4] arm64: mm: Implement pte_devmap support

[Will Deacon]

On Tue, May 28, 2019 at 02:46:59PM +0100, Robin Murphy wrote:
> In order for things like get_user_pages() to work on ZONE_DEVICE memory,
> we need a software PTE bit to identify device-backed PFNs. Hook this up
> along with the relevant helpers to join in with ARCH_HAS_PTE_DEVMAP.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> 
> Fix to build correctly under all combinations of
> CONFIG_PGTABLE_LEVELS and CONFIG_TRANSPARENT_HUGEPAGE.
> 
>  arch/arm64/Kconfig                    |  1 +
>  arch/arm64/include/asm/pgtable-prot.h |  1 +
>  arch/arm64/include/asm/pgtable.h      | 21 +++++++++++++++++++++
>  3 files changed, 23 insertions(+)

Acked-by: Will Deacon <will.deacon@arm.com>

Andrew -- please can you update the previous version of this patch, which
I think you picked up?

Thanks,

Will

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Christoph Hellwig]

Robin, Andrew:

I have a series for the hmm tree, which touches the section size
bits, and remove device public memory support.

It might be best if we include this series in the hmm tree as well
to avoid conflicts.  Is it ok to include the rebase version of at least
the cleanup part (which looks like it is not required for the actual
arm64 support) in the hmm tree to avoid conflicts?

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Mark Rutland]

On Wed, Jun 26, 2019 at 12:35:33AM -0700, Christoph Hellwig wrote:
> Robin, Andrew:

As a heads-up, Robin is currently on holiday, so this is all down to
Andrew's preference.

> I have a series for the hmm tree, which touches the section size
> bits, and remove device public memory support.
> 
> It might be best if we include this series in the hmm tree as well
> to avoid conflicts.  Is it ok to include the rebase version of at least
> the cleanup part (which looks like it is not required for the actual
> arm64 support) in the hmm tree to avoid conflicts?

Per the cover letter, the arm64 patch has a build dependency on the
others, so that might require a stable brnach for the common prefix.

Thanks,
Mark.

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Christoph Hellwig]

On Wed, Jun 26, 2019 at 01:31:40PM +0100, Mark Rutland wrote:
> On Wed, Jun 26, 2019 at 12:35:33AM -0700, Christoph Hellwig wrote:
> > Robin, Andrew:
> 
> As a heads-up, Robin is currently on holiday, so this is all down to
> Andrew's preference.
> 
> > I have a series for the hmm tree, which touches the section size
> > bits, and remove device public memory support.
> > 
> > It might be best if we include this series in the hmm tree as well
> > to avoid conflicts.  Is it ok to include the rebase version of at least
> > the cleanup part (which looks like it is not required for the actual
> > arm64 support) in the hmm tree to avoid conflicts?
> 
> Per the cover letter, the arm64 patch has a build dependency on the
> others, so that might require a stable brnach for the common prefix.

I guess we'll just have to live with the merge errors then, as the
mm tree is a patch series and thus can't easily use a stable base
tree.  That is unlike Andrew wants to pull in the hmm tree as a prep
patch for the series.

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Jason Gunthorpe]

On Wed, Jun 26, 2019 at 08:38:29AM -0700, Christoph Hellwig wrote:
> On Wed, Jun 26, 2019 at 01:31:40PM +0100, Mark Rutland wrote:
> > On Wed, Jun 26, 2019 at 12:35:33AM -0700, Christoph Hellwig wrote:
> > > Robin, Andrew:
> > 
> > As a heads-up, Robin is currently on holiday, so this is all down to
> > Andrew's preference.
> > 
> > > I have a series for the hmm tree, which touches the section size
> > > bits, and remove device public memory support.
> > > 
> > > It might be best if we include this series in the hmm tree as well
> > > to avoid conflicts.  Is it ok to include the rebase version of at least
> > > the cleanup part (which looks like it is not required for the actual
> > > arm64 support) in the hmm tree to avoid conflicts?
> > 
> > Per the cover letter, the arm64 patch has a build dependency on the
> > others, so that might require a stable brnach for the common prefix.
> 
> I guess we'll just have to live with the merge errors then, as the
> mm tree is a patch series and thus can't easily use a stable base
> tree.  That is unlike Andrew wants to pull in the hmm tree as a prep
> patch for the series.

It looks like the first three patches apply cleanly to hmm.git ..

So what we can do is base this 4 patch series off rc6 and pull the
first 3 into hmm and the full 4 into arm.git. We use this workflow often
with rdma and netdev.

Let me know and I can help orchestate this.

Jason

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Andrew Morton]

On Wed, 26 Jun 2019 15:45:47 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:

> On Wed, Jun 26, 2019 at 08:38:29AM -0700, Christoph Hellwig wrote:
> > On Wed, Jun 26, 2019 at 01:31:40PM +0100, Mark Rutland wrote:
> > > On Wed, Jun 26, 2019 at 12:35:33AM -0700, Christoph Hellwig wrote:
> > > > Robin, Andrew:
> > > 
> > > As a heads-up, Robin is currently on holiday, so this is all down to
> > > Andrew's preference.
> > > 
> > > > I have a series for the hmm tree, which touches the section size
> > > > bits, and remove device public memory support.
> > > > 
> > > > It might be best if we include this series in the hmm tree as well
> > > > to avoid conflicts.  Is it ok to include the rebase version of at least
> > > > the cleanup part (which looks like it is not required for the actual
> > > > arm64 support) in the hmm tree to avoid conflicts?
> > > 
> > > Per the cover letter, the arm64 patch has a build dependency on the
> > > others, so that might require a stable brnach for the common prefix.
> > 
> > I guess we'll just have to live with the merge errors then, as the
> > mm tree is a patch series and thus can't easily use a stable base
> > tree.  That is unlike Andrew wants to pull in the hmm tree as a prep
> > patch for the series.
> 
> It looks like the first three patches apply cleanly to hmm.git ..
> 
> So what we can do is base this 4 patch series off rc6 and pull the
> first 3 into hmm and the full 4 into arm.git. We use this workflow often
> with rdma and netdev.
> 
> Let me know and I can help orchestate this.

Well.  Whatever works.  In this situation I'd stage the patches after
linux-next and would merge them up after the prereq patches have been
merged into mainline.  Easy.

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Andrew Morton]

On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> > Let me know and I can help orchestate this.
> 
> Well.  Whatever works.  In this situation I'd stage the patches after
> linux-next and would merge them up after the prereq patches have been
> merged into mainline.  Easy.

All right, what the hell just happened?  A bunch of new material has
just been introduced into linux-next.  I've partially unpicked the
resulting mess, haven't dared trying to compile it yet.  To get this
far I'll need to drop two patch series and one individual patch:


mm-clean-up-is_device__page-definitions.patch
mm-introduce-arch_has_pte_devmap.patch
arm64-mm-implement-pte_devmap-support.patch
arm64-mm-implement-pte_devmap-support-fix.patch

mm-sparsemem-introduce-struct-mem_section_usage.patch
mm-sparsemem-introduce-a-section_is_early-flag.patch
mm-sparsemem-add-helpers-track-active-portions-of-a-section-at-boot.patch
mm-hotplug-prepare-shrink_zone-pgdat_span-for-sub-section-removal.patch
mm-sparsemem-convert-kmalloc_section_memmap-to-populate_section_memmap.patch
mm-hotplug-kill-is_dev_zone-usage-in-__remove_pages.patch
mm-kill-is_dev_zone-helper.patch
mm-sparsemem-prepare-for-sub-section-ranges.patch
mm-sparsemem-support-sub-section-hotplug.patch
mm-document-zone_device-memory-model-implications.patch
mm-document-zone_device-memory-model-implications-fix.patch
mm-devm_memremap_pages-enable-sub-section-remap.patch
libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
libnvdimm-pfn-stop-padding-pmem-namespaces-to-section-alignment.patch

mm-sparsemem-cleanup-section-number-data-types.patch
mm-sparsemem-cleanup-section-number-data-types-fix.patch


I thought you were just going to move material out of -mm and into
hmm.git.  Didn't begin to suspect that new and quite disruptive
material would be introduced late in -rc7!!

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Jason Gunthorpe]

On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote:
> On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > Let me know and I can help orchestate this.
> > 
> > Well.  Whatever works.  In this situation I'd stage the patches after
> > linux-next and would merge them up after the prereq patches have been
> > merged into mainline.  Easy.
> 
> All right, what the hell just happened? 

Christoph's patch series for the devmap & hmm rework finally made it
into linux-next, sorry, it took quite a few iterations on the list to
get all the reviews and tests, and figure out how to resolve some
other conflicting things. So it just made it this week.

Recall, this is the patch series I asked you about routing a few weeks
ago, as it really exceeded the small area that hmm.git was supposed to
cover. I think we are both caught off guard how big the conflict is!

> A bunch of new material has just been introduced into linux-next.
> I've partially unpicked the resulting mess, haven't dared trying to
> compile it yet.  To get this far I'll need to drop two patch series
> and one individual patch:
  
> mm-clean-up-is_device__page-definitions.patch
> mm-introduce-arch_has_pte_devmap.patch
> arm64-mm-implement-pte_devmap-support.patch
> arm64-mm-implement-pte_devmap-support-fix.patch

This one we discussed, and I thought we agreed would go to your 'stage
after linux-next' flow (see above). I think the conflict was minor
here.

> mm-sparsemem-introduce-struct-mem_section_usage.patch
> mm-sparsemem-introduce-a-section_is_early-flag.patch
> mm-sparsemem-add-helpers-track-active-portions-of-a-section-at-boot.patch
> mm-hotplug-prepare-shrink_zone-pgdat_span-for-sub-section-removal.patch
> mm-sparsemem-convert-kmalloc_section_memmap-to-populate_section_memmap.patch
> mm-hotplug-kill-is_dev_zone-usage-in-__remove_pages.patch
> mm-kill-is_dev_zone-helper.patch
> mm-sparsemem-prepare-for-sub-section-ranges.patch
> mm-sparsemem-support-sub-section-hotplug.patch
> mm-document-zone_device-memory-model-implications.patch
> mm-document-zone_device-memory-model-implications-fix.patch
> mm-devm_memremap_pages-enable-sub-section-remap.patch
> libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
> libnvdimm-pfn-stop-padding-pmem-namespaces-to-section-alignment.patch

Dan pointed to this while reviewing CH's series and said the conflicts
would be manageable, but they are certainly larger than I expected!

This series is the one that seems to be the really big trouble. I
already checked all the other stuff that Stephen resolved, and it
looks OK and managable. Just this one conflict with kernel/memremap.c
is beyond me. 

What approach do you want to take to go forward? Here are some thoughts:

CH has said he is away for the long weekend, so the path that involves
the fewest people is if Dan respins the above on linux-next and it
goes later with the arm patches above, assuming defering it for now
has no other adverse effects on -mm.

Pushing CH's series to -mm would need a respin on top of Dan's series
above and would need to carry along the whole hmm.git (about 44
patches). Signs are that this could be managed with the code currently
in the GPU trees.

If we give up on CH's series the hmm.git will not have conflicts,
however we just kick the can to the next merge window where we will be
back to having to co-ordinate amd/nouveau/rdma git trees and -mm's
patch workflow - and I think we will be worse off as we will have
totally given up on a git based work flow for this. :(

> mm-sparsemem-cleanup-section-number-data-types.patch
> mm-sparsemem-cleanup-section-number-data-types-fix.patch

Stephen used a minor conflict resolution for this one, I checked it
carefully and it looked OK.

> I thought you were just going to move material out of -mm and into
> hmm.git.  

Dan brought up a patch from Ira conflicting with CH's work and we did
handle that by moving a single patch, as well I moved several hmm
specific patches early in the cycle.

> Didn't begin to suspect that new and quite disruptive material would
> be introduced late in -rc7!!

Unfortunately a non-rebasing tree like hmm.git should only get patches
into linux-next once they are fully reviewed and done on the list. I
did not attempt to run separately patches 'under review' into
linux-next as you do. 

Actually I didn't even know this would benefit your workflow, rebasing
patches on top of linux-next is not part of the git based workflow I'm
using :(

AFAIK Dan and CH were both tracking conflicts with linux-next, so I'd
like to hear from Dan what he thinks about his series, maybe the
rebase is simple & safe for him? Dan and CH were working pretty
closely on CH's series.

Jason

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Andrew Morton]

On Thu, 4 Jul 2019 19:59:38 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:

> On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote:
> > On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > > > Let me know and I can help orchestate this.
> > > 
> > > Well.  Whatever works.  In this situation I'd stage the patches after
> > > linux-next and would merge them up after the prereq patches have been
> > > merged into mainline.  Easy.
> > 
> > All right, what the hell just happened? 
> 
> Christoph's patch series for the devmap & hmm rework finally made it
> into linux-next

We're talking about "dev_pagemap related cleanups v4", yes?

I note that linux-next contains "mm: remove the HMM config option"
which was present in Christoph's v3 series but wasn't present in v4. 
Perhaps something has gone wrong here.

> sorry, it took quite a few iterations on the list to
> get all the reviews and tests, and figure out how to resolve some
> other conflicting things. So it just made it this week.
> 
> Recall, this is the patch series I asked you about routing a few weeks
> ago, as it really exceeded the small area that hmm.git was supposed to
> cover. I think we are both caught off guard how big the conflict is!

I guess I was distracted - I should have taken a look to see how
mergable it all was.

It's a large patchset and it appears to be mainly (entirely?) code
cleanups.  I don't think such material would be appropriate for a late
-rc7 merge even if it didn't conflict with lots of other higher
priority pending functional changes and fixes!

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Robin Murphy]

On 2019-07-04 8:59 pm, Jason Gunthorpe wrote:
> On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote:
>> On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>>>> Let me know and I can help orchestate this.
>>>
>>> Well.  Whatever works.  In this situation I'd stage the patches after
>>> linux-next and would merge them up after the prereq patches have been
>>> merged into mainline.  Easy.
>>
>> All right, what the hell just happened?

Aw crap, and I had this series chalked up as done...

> Christoph's patch series for the devmap & hmm rework finally made it
> into linux-next, sorry, it took quite a few iterations on the list to
> get all the reviews and tests, and figure out how to resolve some
> other conflicting things. So it just made it this week.
> 
> Recall, this is the patch series I asked you about routing a few weeks
> ago, as it really exceeded the small area that hmm.git was supposed to
> cover. I think we are both caught off guard how big the conflict is!
> 
>> A bunch of new material has just been introduced into linux-next.
>> I've partially unpicked the resulting mess, haven't dared trying to
>> compile it yet.  To get this far I'll need to drop two patch series
>> and one individual patch:
>    
>> mm-clean-up-is_device__page-definitions.patch
>> mm-introduce-arch_has_pte_devmap.patch
>> arm64-mm-implement-pte_devmap-support.patch
>> arm64-mm-implement-pte_devmap-support-fix.patch
> 
> This one we discussed, and I thought we agreed would go to your 'stage
> after linux-next' flow (see above). I think the conflict was minor
> here.

I can rebase and resend tomorrow if there's an agreement on what exactly 
to base it on - I'd really like to get this ticked off for 5.3 if at all 
possible.

Thanks,
Robin.

>> mm-sparsemem-introduce-struct-mem_section_usage.patch
>> mm-sparsemem-introduce-a-section_is_early-flag.patch
>> mm-sparsemem-add-helpers-track-active-portions-of-a-section-at-boot.patch
>> mm-hotplug-prepare-shrink_zone-pgdat_span-for-sub-section-removal.patch
>> mm-sparsemem-convert-kmalloc_section_memmap-to-populate_section_memmap.patch
>> mm-hotplug-kill-is_dev_zone-usage-in-__remove_pages.patch
>> mm-kill-is_dev_zone-helper.patch
>> mm-sparsemem-prepare-for-sub-section-ranges.patch
>> mm-sparsemem-support-sub-section-hotplug.patch
>> mm-document-zone_device-memory-model-implications.patch
>> mm-document-zone_device-memory-model-implications-fix.patch
>> mm-devm_memremap_pages-enable-sub-section-remap.patch
>> libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
>> libnvdimm-pfn-stop-padding-pmem-namespaces-to-section-alignment.patch
> 
> Dan pointed to this while reviewing CH's series and said the conflicts
> would be manageable, but they are certainly larger than I expected!
> 
> This series is the one that seems to be the really big trouble. I
> already checked all the other stuff that Stephen resolved, and it
> looks OK and managable. Just this one conflict with kernel/memremap.c
> is beyond me.
> 
> What approach do you want to take to go forward? Here are some thoughts:
> 
> CH has said he is away for the long weekend, so the path that involves
> the fewest people is if Dan respins the above on linux-next and it
> goes later with the arm patches above, assuming defering it for now
> has no other adverse effects on -mm.
> 
> Pushing CH's series to -mm would need a respin on top of Dan's series
> above and would need to carry along the whole hmm.git (about 44
> patches). Signs are that this could be managed with the code currently
> in the GPU trees.
> 
> If we give up on CH's series the hmm.git will not have conflicts,
> however we just kick the can to the next merge window where we will be
> back to having to co-ordinate amd/nouveau/rdma git trees and -mm's
> patch workflow - and I think we will be worse off as we will have
> totally given up on a git based work flow for this. :(
> 
>> mm-sparsemem-cleanup-section-number-data-types.patch
>> mm-sparsemem-cleanup-section-number-data-types-fix.patch
> 
> Stephen used a minor conflict resolution for this one, I checked it
> carefully and it looked OK.
> 
>> I thought you were just going to move material out of -mm and into
>> hmm.git.
> 
> Dan brought up a patch from Ira conflicting with CH's work and we did
> handle that by moving a single patch, as well I moved several hmm
> specific patches early in the cycle.
> 
>> Didn't begin to suspect that new and quite disruptive material would
>> be introduced late in -rc7!!
> 
> Unfortunately a non-rebasing tree like hmm.git should only get patches
> into linux-next once they are fully reviewed and done on the list. I
> did not attempt to run separately patches 'under review' into
> linux-next as you do.
> 
> Actually I didn't even know this would benefit your workflow, rebasing
> patches on top of linux-next is not part of the git based workflow I'm
> using :(
> 
> AFAIK Dan and CH were both tracking conflicts with linux-next, so I'd
> like to hear from Dan what he thinks about his series, maybe the
> rebase is simple & safe for him? Dan and CH were working pretty
> closely on CH's series.
> 
> Jason
> 

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Andrew Morton]

On Thu, 4 Jul 2019 21:54:36 +0100 Robin Murphy <robin.murphy@arm.com> wrote:

> >> mm-clean-up-is_device__page-definitions.patch
> >> mm-introduce-arch_has_pte_devmap.patch
> >> arm64-mm-implement-pte_devmap-support.patch
> >> arm64-mm-implement-pte_devmap-support-fix.patch
> > 
> > This one we discussed, and I thought we agreed would go to your 'stage
> > after linux-next' flow (see above). I think the conflict was minor
> > here.
> 
> I can rebase and resend tomorrow if there's an agreement on what exactly 
> to base it on - I'd really like to get this ticked off for 5.3 if at all 
> possible.

I took another look.  Yes, it looks like the repairs were simple.

Let me now try to compile all this...

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Jason Gunthorpe]

On Thu, Jul 04, 2019 at 01:53:32PM -0700, Andrew Morton wrote:
> On Thu, 4 Jul 2019 19:59:38 +0000 Jason Gunthorpe <jgg@mellanox.com> wrote:
> 
> > On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote:
> > > On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > > 
> > > > > Let me know and I can help orchestate this.
> > > > 
> > > > Well.  Whatever works.  In this situation I'd stage the patches after
> > > > linux-next and would merge them up after the prereq patches have been
> > > > merged into mainline.  Easy.
> > > 
> > > All right, what the hell just happened? 
> > 
> > Christoph's patch series for the devmap & hmm rework finally made it
> > into linux-next
> 
> We're talking about "dev_pagemap related cleanups v4", yes?
>
> I note that linux-next contains "mm: remove the HMM config option"
> which was present in Christoph's v3 series but wasn't present in v4. 
> Perhaps something has gone wrong here.

When CH sent v4 to the list it was corrupted, v3 is the one to
reference for content.

Here is the mailing thread discussing this:

https://lore.kernel.org/linux-mm/20190702184201.GO31718@mellanox.com/

> > sorry, it took quite a few iterations on the list to
> > get all the reviews and tests, and figure out how to resolve some
> > other conflicting things. So it just made it this week.
> > 
> > Recall, this is the patch series I asked you about routing a few weeks
> > ago, as it really exceeded the small area that hmm.git was supposed to
> > cover. I think we are both caught off guard how big the conflict is!
> 
> I guess I was distracted - I should have taken a look to see how
> mergable it all was.

Okay, fair enough. I also could have also done more checks myself with
linux-next

> It's a large patchset and it appears to be mainly (entirely?) code
> cleanups.  I don't think such material would be appropriate for a late
> -rc7 merge even if it didn't conflict with lots of other higher
> priority pending functional changes and fixes!

I see your other email you resolved the conflicts - so please let me
know if you want to proceed with dropping CH's series or not, I'll
make a special effort to get that change into tomorrows linux-next if
you want (it is already 6pm here)

Regards,
Jason

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Dan Williams]

On Thu, Jul 4, 2019 at 12:59 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote:
> > On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > > Let me know and I can help orchestate this.
> > >
> > > Well.  Whatever works.  In this situation I'd stage the patches after
> > > linux-next and would merge them up after the prereq patches have been
> > > merged into mainline.  Easy.
> >
> > All right, what the hell just happened?
>
> Christoph's patch series for the devmap & hmm rework finally made it
> into linux-next, sorry, it took quite a few iterations on the list to
> get all the reviews and tests, and figure out how to resolve some
> other conflicting things. So it just made it this week.
>
> Recall, this is the patch series I asked you about routing a few weeks
> ago, as it really exceeded the small area that hmm.git was supposed to
> cover. I think we are both caught off guard how big the conflict is!
>
> > A bunch of new material has just been introduced into linux-next.
> > I've partially unpicked the resulting mess, haven't dared trying to
> > compile it yet.  To get this far I'll need to drop two patch series
> > and one individual patch:
>
> > mm-clean-up-is_device__page-definitions.patch
> > mm-introduce-arch_has_pte_devmap.patch
> > arm64-mm-implement-pte_devmap-support.patch
> > arm64-mm-implement-pte_devmap-support-fix.patch
>
> This one we discussed, and I thought we agreed would go to your 'stage
> after linux-next' flow (see above). I think the conflict was minor
> here.
>
> > mm-sparsemem-introduce-struct-mem_section_usage.patch
> > mm-sparsemem-introduce-a-section_is_early-flag.patch
> > mm-sparsemem-add-helpers-track-active-portions-of-a-section-at-boot.patch
> > mm-hotplug-prepare-shrink_zone-pgdat_span-for-sub-section-removal.patch
> > mm-sparsemem-convert-kmalloc_section_memmap-to-populate_section_memmap.patch
> > mm-hotplug-kill-is_dev_zone-usage-in-__remove_pages.patch
> > mm-kill-is_dev_zone-helper.patch
> > mm-sparsemem-prepare-for-sub-section-ranges.patch
> > mm-sparsemem-support-sub-section-hotplug.patch
> > mm-document-zone_device-memory-model-implications.patch
> > mm-document-zone_device-memory-model-implications-fix.patch
> > mm-devm_memremap_pages-enable-sub-section-remap.patch
> > libnvdimm-pfn-fix-fsdax-mode-namespace-info-block-zero-fields.patch
> > libnvdimm-pfn-stop-padding-pmem-namespaces-to-section-alignment.patch
>
> Dan pointed to this while reviewing CH's series and said the conflicts
> would be manageable, but they are certainly larger than I expected!
>
> This series is the one that seems to be the really big trouble. I
> already checked all the other stuff that Stephen resolved, and it
> looks OK and managable. Just this one conflict with kernel/memremap.c
> is beyond me.
>
> What approach do you want to take to go forward? Here are some thoughts:
>
> CH has said he is away for the long weekend, so the path that involves
> the fewest people is if Dan respins the above on linux-next and it
> goes later with the arm patches above, assuming defering it for now
> has no other adverse effects on -mm.
>
> Pushing CH's series to -mm would need a respin on top of Dan's series
> above and would need to carry along the whole hmm.git (about 44
> patches). Signs are that this could be managed with the code currently
> in the GPU trees.
>
> If we give up on CH's series the hmm.git will not have conflicts,
> however we just kick the can to the next merge window where we will be
> back to having to co-ordinate amd/nouveau/rdma git trees and -mm's
> patch workflow - and I think we will be worse off as we will have
> totally given up on a git based work flow for this. :(

I think the problem would be resolved going forward post-v5.3 since we
won't have two tress managing kernel/memremap.c. This cycle however
there is a backlog of kernel/memremap.c changes in -mm.

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Robin Murphy]

On 04/07/2019 22:13, Andrew Morton wrote:
> On Thu, 4 Jul 2019 21:54:36 +0100 Robin Murphy <robin.murphy@arm.com> wrote:
> 
>>>> mm-clean-up-is_device__page-definitions.patch
>>>> mm-introduce-arch_has_pte_devmap.patch
>>>> arm64-mm-implement-pte_devmap-support.patch
>>>> arm64-mm-implement-pte_devmap-support-fix.patch
>>>
>>> This one we discussed, and I thought we agreed would go to your 'stage
>>> after linux-next' flow (see above). I think the conflict was minor
>>> here.
>>
>> I can rebase and resend tomorrow if there's an agreement on what exactly
>> to base it on - I'd really like to get this ticked off for 5.3 if at all
>> possible.
> 
> I took another look.  Yes, it looks like the repairs were simple.
> 
> Let me now try to compile all this...

Thanks, the revised patches look OK to me, and I've confirmed that 
today's -next builds and boots for arm64.

Cheers,
Robin.

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Jason Gunthorpe]

On Thu, Jul 04, 2019 at 04:37:51PM -0700, Dan Williams wrote:

> > If we give up on CH's series the hmm.git will not have conflicts,
> > however we just kick the can to the next merge window where we will be
> > back to having to co-ordinate amd/nouveau/rdma git trees and -mm's
> > patch workflow - and I think we will be worse off as we will have
> > totally given up on a git based work flow for this. :(
> 
> I think the problem would be resolved going forward post-v5.3 since we
> won't have two tress managing kernel/memremap.c. This cycle however
> there is a backlog of kernel/memremap.c changes in -mm.

IHMO there is always something :( 

CH's series had something like 5 different collisions already, and I
think we did a good job of with everything but your subsection
patches.

Jason

Re: [PATCH v3 0/4] Devmap cleanups + arm64 support

[Jason Gunthorpe]

On Thu, Jul 04, 2019 at 06:28:50PM -0300, Jason Gunthorpe wrote:

> > It's a large patchset and it appears to be mainly (entirely?) code
> > cleanups.  I don't think such material would be appropriate for a late
> > -rc7 merge even if it didn't conflict with lots of other higher
> > priority pending functional changes and fixes!
> 
> I see your other email you resolved the conflicts - so please let me
> know if you want to proceed with dropping CH's series or not, I'll
> make a special effort to get that change into tomorrows linux-next if
> you want (it is already 6pm here)

I spent some time this morning looking at the various conflicts, and I
think Dan is right, they are mangable. In the sense we can forward a
merge resolution to Linus and it is not completely crazy. Most hunks
are the usual mechanical sort of conflicts.

Like Stephen, only two small conflict hunks in the memremap.c give me
any pause, and I'm confident with CH and Dan's help it can be resolved
robustly. If Linus doesn't like it then we fall back to dropping CH's
series.

So, here is a fourth idea..

We remove hmm.git entirely from your workflow (ie you revert commit
"cc5dfd59e375f Merge branch 'hmm-devmem-cleanup.4' into rdma.git hmm"
in your local version of linux-next) and I will send hmm.git to Linus
after Dan's patches and others are merged by you to Linus. With Dan
and CH's help I will forward the reviewed conflict resolution.

This will not disturb the -mm patch workflow at all, and you can put
everything back the way it was on July 3.

What do you think about this?

Jason