Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
@ 2021-04-21  6:51 Mike Rapoport
  2021-04-21  6:51 ` [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid() Mike Rapoport
                   ` (4 more replies)
  0 siblings, 5 replies; 39+ messages in thread
From: Mike Rapoport @ 2021-04-21  6:51 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, David Hildenbrand, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

From: Mike Rapoport <rppt@linux.ibm.com>

Hi,

These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1. 

The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn.

With this the core mm will be able to cope with the fact that it cannot use
NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
will be treated correctly even without the need for pfn_valid_within.

The patches are only boot tested on qemu-system-aarch64 so I'd really
appreciate memory stress tests on real hardware.

If this actually works we'll be one step closer to drop custom pfn_valid()
on arm64 altogether.

v2:
* Add check for PFN overflow in pfn_is_map_memory()
* Add Acked-by and Reviewed-by tags, thanks David.

v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-rppt@kernel.org
* Add comment about the semantics of pfn_valid() as Anshuman suggested
* Extend comments about MEMBLOCK_NOMAP, per Anshuman
* Use pfn_is_map_memory() name for the exported wrapper for
  memblock_is_map_memory(). It is still local to arch/arm64 in the end
  because of header dependency issues.

rfc: Link: https://lore.kernel.org/lkml/20210407172607.8812-1-rppt@kernel.org

Mike Rapoport (4):
  include/linux/mmzone.h: add documentation for pfn_valid()
  memblock: update initialization of reserved pages
  arm64: decouple check whether pfn is in linear map from pfn_valid()
  arm64: drop pfn_valid_within() and simplify pfn_valid()

 arch/arm64/Kconfig              |  3 ---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 10 ++++++++--
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 include/linux/memblock.h        |  4 +++-
 include/linux/mmzone.h          | 11 +++++++++++
 mm/memblock.c                   | 28 ++++++++++++++++++++++++++--
 10 files changed, 54 insertions(+), 13 deletions(-)

base-commit: e49d033bddf5b565044e2abe4241353959bc9120
-- 
2.28.0

*** BLURB HERE ***

Mike Rapoport (4):
  include/linux/mmzone.h: add documentation for pfn_valid()
  memblock: update initialization of reserved pages
  arm64: decouple check whether pfn is in linear map from pfn_valid()
  arm64: drop pfn_valid_within() and simplify pfn_valid()

 arch/arm64/Kconfig              |  3 ---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 15 +++++++++++++--
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 include/linux/memblock.h        |  4 +++-
 include/linux/mmzone.h          | 11 +++++++++++
 mm/memblock.c                   | 28 ++++++++++++++++++++++++++--
 10 files changed, 59 insertions(+), 13 deletions(-)

-- 
2.28.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid()
  2021-04-21  6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
@ 2021-04-21  6:51 ` Mike Rapoport
  2021-04-21 10:49   ` Anshuman Khandual
  2021-04-21  6:51 ` [PATCH v2 2/4] memblock: update initialization of reserved pages Mike Rapoport
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-21  6:51 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, David Hildenbrand, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

From: Mike Rapoport <rppt@linux.ibm.com>

Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.

The most "generic" version of pfn_valid() used by the configurations with
SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
suitable place for documentation about semantics of pfn_valid().

Suggested-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 include/linux/mmzone.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 47946cec7584..961f0eeefb62 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
 #endif
 
 #ifndef CONFIG_HAVE_ARCH_PFN_VALID
+/**
+ * pfn_valid - check if there is a valid memory map entry for a PFN
+ * @pfn: the page frame number to check
+ *
+ * Check if there is a valid memory map entry aka struct page for the @pfn.
+ * Note, that availability of the memory map entry does not imply that
+ * there is actual usable memory at that @pfn. The struct page may
+ * represent a hole or an unusable page frame.
+ *
+ * Return: 1 for PFNs that have memory map entries and 0 otherwise
+ */
 static inline int pfn_valid(unsigned long pfn)
 {
 	struct mem_section *ms;
-- 
2.28.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [PATCH v2 2/4] memblock: update initialization of reserved pages
  2021-04-21  6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
  2021-04-21  6:51 ` [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid() Mike Rapoport
@ 2021-04-21  6:51 ` Mike Rapoport
  2021-04-21  7:49   ` David Hildenbrand
  2021-04-21 10:51   ` Anshuman Khandual
  2021-04-21  6:51 ` [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid() Mike Rapoport
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 39+ messages in thread
From: Mike Rapoport @ 2021-04-21  6:51 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, David Hildenbrand, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

From: Mike Rapoport <rppt@linux.ibm.com>

The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.

The struct pages for MEMBLOCK_NOMAP regions are kept with the default
values set by the memory map initialization which makes it necessary to
have a special treatment for such pages in pfn_valid() and
pfn_valid_within().

Split out initialization of the reserved pages to a function with a
meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
reserved regions and mark struct pages for the NOMAP regions as
PageReserved.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 include/linux/memblock.h |  4 +++-
 mm/memblock.c            | 28 ++++++++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5984fff3f175..634c1a578db8 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
  * @MEMBLOCK_NONE: no special request
  * @MEMBLOCK_HOTPLUG: hotpluggable region
  * @MEMBLOCK_MIRROR: mirrored region
- * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
+ * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
+ * reserved in the memory map; refer to memblock_mark_nomap() description
+ * for futher details
  */
 enum memblock_flags {
 	MEMBLOCK_NONE		= 0x0,	/* No special request */
diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..3abf2c3fea7f 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
  * @base: the base phys addr of the region
  * @size: the size of the region
  *
+ * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
+ * direct mapping of the physical memory. These regions will still be
+ * covered by the memory map. The struct page representing NOMAP memory
+ * frames in the memory map will be PageReserved()
+ *
  * Return: 0 on success, -errno on failure.
  */
 int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
@@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
 	return end_pfn - start_pfn;
 }
 
+static void __init memmap_init_reserved_pages(void)
+{
+	struct memblock_region *region;
+	phys_addr_t start, end;
+	u64 i;
+
+	/* initialize struct pages for the reserved regions */
+	for_each_reserved_mem_range(i, &start, &end)
+		reserve_bootmem_region(start, end);
+
+	/* and also treat struct pages for the NOMAP regions as PageReserved */
+	for_each_mem_region(region) {
+		if (memblock_is_nomap(region)) {
+			start = region->base;
+			end = start + region->size;
+			reserve_bootmem_region(start, end);
+		}
+	}
+}
+
 static unsigned long __init free_low_memory_core_early(void)
 {
 	unsigned long count = 0;
@@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
 
 	memblock_clear_hotplug(0, -1);
 
-	for_each_reserved_mem_range(i, &start, &end)
-		reserve_bootmem_region(start, end);
+	memmap_init_reserved_pages();
 
 	/*
 	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
-- 
2.28.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid()
  2021-04-21  6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
  2021-04-21  6:51 ` [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid() Mike Rapoport
  2021-04-21  6:51 ` [PATCH v2 2/4] memblock: update initialization of reserved pages Mike Rapoport
@ 2021-04-21  6:51 ` Mike Rapoport
  2021-04-21 10:59   ` Anshuman Khandual
  2021-04-21  6:51 ` [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
  2021-04-22  7:00 ` [PATCH v2 0/4] " Kefeng Wang
  4 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-21  6:51 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, David Hildenbrand, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

From: Mike Rapoport <rppt@linux.ibm.com>

The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.

Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.

Introduce a dedicated pfn_is_map_memory() wrapper for
memblock_is_map_memory() to perform such check and use it where
appropriate.

Using a wrapper allows to avoid cyclic include dependencies.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 11 +++++++++++
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 6 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..194f9f993d30 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 
 #define virt_addr_valid(addr)	({					\
 	__typeof__(addr) __addr = __tag_reset(addr);			\
-	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
+	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
 })
 
 void dump_mem_limit(void);
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 012cffc574e8..99a6da91f870 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
 typedef struct page *pgtable_t;
 
 extern int pfn_valid(unsigned long);
+extern int pfn_is_map_memory(unsigned long);
 
 #include <asm/memory.h>
 
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..23dd99e29b23 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
 
 static bool kvm_is_device_pfn(unsigned long pfn)
 {
-	return !pfn_valid(pfn);
+	return !pfn_is_map_memory(pfn);
 }
 
 /*
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3685e12aba9b..dc03bdc12c0f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
 }
 EXPORT_SYMBOL(pfn_valid);
 
+int pfn_is_map_memory(unsigned long pfn)
+{
+	phys_addr_t addr = PFN_PHYS(pfn);
+
+	if (PHYS_PFN(addr) != pfn)
+		return 0;
+	
+	return memblock_is_map_memory(addr);
+}
+EXPORT_SYMBOL(pfn_is_map_memory);
+
 static phys_addr_t memory_limit = PHYS_ADDR_MAX;
 
 /*
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index b5e83c46b23e..b7c81dacabf0 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
 	/*
 	 * Don't allow RAM to be mapped.
 	 */
-	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+	if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
 		return NULL;
 
 	area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
 void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
 {
 	/* For normal memory we already have a cacheable mapping. */
-	if (pfn_valid(__phys_to_pfn(phys_addr)))
+	if (pfn_is_map_memory(__phys_to_pfn(phys_addr)))
 		return (void __iomem *)__phys_to_virt(phys_addr);
 
 	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d9550fdb9cf..26045e9adbd7 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)
 {
-	if (!pfn_valid(pfn))
+	if (!pfn_is_map_memory(pfn))
 		return pgprot_noncached(vma_prot);
 	else if (file->f_flags & O_SYNC)
 		return pgprot_writecombine(vma_prot);
-- 
2.28.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-21  6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
                   ` (2 preceding siblings ...)
  2021-04-21  6:51 ` [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid() Mike Rapoport
@ 2021-04-21  6:51 ` Mike Rapoport
  2021-04-21  7:49   ` David Hildenbrand
  2021-04-21 11:06   ` Anshuman Khandual
  2021-04-22  7:00 ` [PATCH v2 0/4] " Kefeng Wang
  4 siblings, 2 replies; 39+ messages in thread
From: Mike Rapoport @ 2021-04-21  6:51 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, David Hildenbrand, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

From: Mike Rapoport <rppt@linux.ibm.com>

The arm64's version of pfn_valid() differs from the generic because of two
reasons:

* Parts of the memory map are freed during boot. This makes it necessary to
  verify that there is actual physical memory that corresponds to a pfn
  which is done by querying memblock.

* There are NOMAP memory regions. These regions are not mapped in the
  linear map and until the previous commit the struct pages representing
  these areas had default values.

As the consequence of absence of the special treatment of NOMAP regions in
the memory map it was necessary to use memblock_is_map_memory() in
pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
generic mm functionality would not treat a NOMAP page as a normal page.

Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
the rest of core mm will treat them as unusable memory and thus
pfn_valid_within() is no longer required at all and can be disabled by
removing CONFIG_HOLES_IN_ZONE on arm64.

pfn_valid() can be slightly simplified by replacing
memblock_is_map_memory() with memblock_is_memory().

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/arm64/Kconfig   | 3 ---
 arch/arm64/mm/init.c | 4 ++--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..58e439046d05 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
 	def_bool y
 	depends on NUMA
 
-config HOLES_IN_ZONE
-	def_bool y
-
 source "kernel/Kconfig.hz"
 
 config ARCH_SPARSEMEM_ENABLE
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index dc03bdc12c0f..eb3f56fb8c7c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
 
 	/*
 	 * ZONE_DEVICE memory does not have the memblock entries.
-	 * memblock_is_map_memory() check for ZONE_DEVICE based
+	 * memblock_is_memory() check for ZONE_DEVICE based
 	 * addresses will always fail. Even the normal hotplugged
 	 * memory will never have MEMBLOCK_NOMAP flag set in their
 	 * memblock entries. Skip memblock search for all non early
@@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
 		return pfn_section_valid(ms, pfn);
 }
 #endif
-	return memblock_is_map_memory(addr);
+	return memblock_is_memory(addr);
 }
 EXPORT_SYMBOL(pfn_valid);
 
-- 
2.28.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-21  6:51 ` [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
@ 2021-04-21  7:49   ` David Hildenbrand
  2021-04-21 11:06   ` Anshuman Khandual
  1 sibling, 0 replies; 39+ messages in thread
From: David Hildenbrand @ 2021-04-21  7:49 UTC (permalink / raw)
  To: Mike Rapoport, linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm

On 21.04.21 08:51, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
> 
> * Parts of the memory map are freed during boot. This makes it necessary to
>    verify that there is actual physical memory that corresponds to a pfn
>    which is done by querying memblock.
> 
> * There are NOMAP memory regions. These regions are not mapped in the
>    linear map and until the previous commit the struct pages representing
>    these areas had default values.
> 
> As the consequence of absence of the special treatment of NOMAP regions in
> the memory map it was necessary to use memblock_is_map_memory() in
> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> generic mm functionality would not treat a NOMAP page as a normal page.
> 
> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> the rest of core mm will treat them as unusable memory and thus
> pfn_valid_within() is no longer required at all and can be disabled by
> removing CONFIG_HOLES_IN_ZONE on arm64.
> 
> pfn_valid() can be slightly simplified by replacing
> memblock_is_map_memory() with memblock_is_memory().
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>   arch/arm64/Kconfig   | 3 ---
>   arch/arm64/mm/init.c | 4 ++--
>   2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e4e1b6550115..58e439046d05 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>   	def_bool y
>   	depends on NUMA
>   
> -config HOLES_IN_ZONE
> -	def_bool y
> -
>   source "kernel/Kconfig.hz"
>   
>   config ARCH_SPARSEMEM_ENABLE
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index dc03bdc12c0f..eb3f56fb8c7c 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>   
>   	/*
>   	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> +	 * memblock_is_memory() check for ZONE_DEVICE based
>   	 * addresses will always fail. Even the normal hotplugged
>   	 * memory will never have MEMBLOCK_NOMAP flag set in their
>   	 * memblock entries. Skip memblock search for all non early
> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>   		return pfn_section_valid(ms, pfn);
>   }
>   #endif
> -	return memblock_is_map_memory(addr);
> +	return memblock_is_memory(addr);
>   }
>   EXPORT_SYMBOL(pfn_valid);
>   
> 

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 2/4] memblock: update initialization of reserved pages
  2021-04-21  6:51 ` [PATCH v2 2/4] memblock: update initialization of reserved pages Mike Rapoport
@ 2021-04-21  7:49   ` David Hildenbrand
  2021-04-21 10:51   ` Anshuman Khandual
  1 sibling, 0 replies; 39+ messages in thread
From: David Hildenbrand @ 2021-04-21  7:49 UTC (permalink / raw)
  To: Mike Rapoport, linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm

On 21.04.21 08:51, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
> page allocator.
> 
> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> values set by the memory map initialization which makes it necessary to
> have a special treatment for such pages in pfn_valid() and
> pfn_valid_within().
> 
> Split out initialization of the reserved pages to a function with a
> meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> reserved regions and mark struct pages for the NOMAP regions as
> PageReserved.
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>   include/linux/memblock.h |  4 +++-
>   mm/memblock.c            | 28 ++++++++++++++++++++++++++--
>   2 files changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5984fff3f175..634c1a578db8 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
>    * @MEMBLOCK_NONE: no special request
>    * @MEMBLOCK_HOTPLUG: hotpluggable region
>    * @MEMBLOCK_MIRROR: mirrored region
> - * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
> + * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> + * reserved in the memory map; refer to memblock_mark_nomap() description
> + * for futher details
>    */
>   enum memblock_flags {
>   	MEMBLOCK_NONE		= 0x0,	/* No special request */
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..3abf2c3fea7f 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
>    * @base: the base phys addr of the region
>    * @size: the size of the region
>    *
> + * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
> + * direct mapping of the physical memory. These regions will still be
> + * covered by the memory map. The struct page representing NOMAP memory
> + * frames in the memory map will be PageReserved()
> + *
>    * Return: 0 on success, -errno on failure.
>    */
>   int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
> @@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>   	return end_pfn - start_pfn;
>   }
>   
> +static void __init memmap_init_reserved_pages(void)
> +{
> +	struct memblock_region *region;
> +	phys_addr_t start, end;
> +	u64 i;
> +
> +	/* initialize struct pages for the reserved regions */
> +	for_each_reserved_mem_range(i, &start, &end)
> +		reserve_bootmem_region(start, end);
> +
> +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> +	for_each_mem_region(region) {
> +		if (memblock_is_nomap(region)) {
> +			start = region->base;
> +			end = start + region->size;
> +			reserve_bootmem_region(start, end);
> +		}
> +	}
> +}
> +
>   static unsigned long __init free_low_memory_core_early(void)
>   {
>   	unsigned long count = 0;
> @@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
>   
>   	memblock_clear_hotplug(0, -1);
>   
> -	for_each_reserved_mem_range(i, &start, &end)
> -		reserve_bootmem_region(start, end);
> +	memmap_init_reserved_pages();
>   
>   	/*
>   	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid()
  2021-04-21  6:51 ` [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid() Mike Rapoport
@ 2021-04-21 10:49   ` Anshuman Khandual
  0 siblings, 0 replies; 39+ messages in thread
From: Anshuman Khandual @ 2021-04-21 10:49 UTC (permalink / raw)
  To: Mike Rapoport, linux-arm-kernel
  Cc: Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm

On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> Add comment describing the semantics of pfn_valid() that clarifies that
> pfn_valid() only checks for availability of a memory map entry (i.e. struct
> page) for a PFN rather than availability of usable memory backing that PFN.
> 
> The most "generic" version of pfn_valid() used by the configurations with
> SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
> suitable place for documentation about semantics of pfn_valid().
> 
> Suggested-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>

Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>

> ---
>  include/linux/mmzone.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 47946cec7584..961f0eeefb62 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>  #endif
>  
>  #ifndef CONFIG_HAVE_ARCH_PFN_VALID
> +/**
> + * pfn_valid - check if there is a valid memory map entry for a PFN
> + * @pfn: the page frame number to check
> + *
> + * Check if there is a valid memory map entry aka struct page for the @pfn.
> + * Note, that availability of the memory map entry does not imply that
> + * there is actual usable memory at that @pfn. The struct page may
> + * represent a hole or an unusable page frame.
> + *
> + * Return: 1 for PFNs that have memory map entries and 0 otherwise
> + */
>  static inline int pfn_valid(unsigned long pfn)
>  {
>  	struct mem_section *ms;
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 2/4] memblock: update initialization of reserved pages
  2021-04-21  6:51 ` [PATCH v2 2/4] memblock: update initialization of reserved pages Mike Rapoport
  2021-04-21  7:49   ` David Hildenbrand
@ 2021-04-21 10:51   ` Anshuman Khandual
  1 sibling, 0 replies; 39+ messages in thread
From: Anshuman Khandual @ 2021-04-21 10:51 UTC (permalink / raw)
  To: Mike Rapoport, linux-arm-kernel
  Cc: Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm


On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
> page allocator.
> 
> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> values set by the memory map initialization which makes it necessary to
> have a special treatment for such pages in pfn_valid() and
> pfn_valid_within().
> 
> Split out initialization of the reserved pages to a function with a
> meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> reserved regions and mark struct pages for the NOMAP regions as
> PageReserved.
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>  include/linux/memblock.h |  4 +++-
>  mm/memblock.c            | 28 ++++++++++++++++++++++++++--
>  2 files changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5984fff3f175..634c1a578db8 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
>   * @MEMBLOCK_NONE: no special request
>   * @MEMBLOCK_HOTPLUG: hotpluggable region
>   * @MEMBLOCK_MIRROR: mirrored region
> - * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
> + * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> + * reserved in the memory map; refer to memblock_mark_nomap() description
> + * for futher details

Small nit - s/futher/further

>   */
>  enum memblock_flags {
>  	MEMBLOCK_NONE		= 0x0,	/* No special request */
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..3abf2c3fea7f 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
>   * @base: the base phys addr of the region
>   * @size: the size of the region
>   *
> + * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
> + * direct mapping of the physical memory. These regions will still be
> + * covered by the memory map. The struct page representing NOMAP memory
> + * frames in the memory map will be PageReserved()
> + *
>   * Return: 0 on success, -errno on failure.
>   */
>  int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
> @@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>  	return end_pfn - start_pfn;
>  }
>  
> +static void __init memmap_init_reserved_pages(void)
> +{
> +	struct memblock_region *region;
> +	phys_addr_t start, end;
> +	u64 i;
> +
> +	/* initialize struct pages for the reserved regions */
> +	for_each_reserved_mem_range(i, &start, &end)
> +		reserve_bootmem_region(start, end);
> +
> +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> +	for_each_mem_region(region) {
> +		if (memblock_is_nomap(region)) {
> +			start = region->base;
> +			end = start + region->size;
> +			reserve_bootmem_region(start, end);
> +		}
> +	}

I guess there is no possible method to unify both these loops.

> +}
> +
>  static unsigned long __init free_low_memory_core_early(void)
>  {
>  	unsigned long count = 0;
> @@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
>  
>  	memblock_clear_hotplug(0, -1);
>  
> -	for_each_reserved_mem_range(i, &start, &end)
> -		reserve_bootmem_region(start, end);
> +	memmap_init_reserved_pages();
>  
>  	/*
>  	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> 


Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid()
  2021-04-21  6:51 ` [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid() Mike Rapoport
@ 2021-04-21 10:59   ` Anshuman Khandual
  2021-04-21 12:19     ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Anshuman Khandual @ 2021-04-21 10:59 UTC (permalink / raw)
  To: Mike Rapoport, linux-arm-kernel
  Cc: Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm


On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> The intended semantics of pfn_valid() is to verify whether there is a
> struct page for the pfn in question and nothing else.
> 
> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> linear map vs those that require ioremap() to access them.
> 
> Introduce a dedicated pfn_is_map_memory() wrapper for
> memblock_is_map_memory() to perform such check and use it where
> appropriate.
> 
> Using a wrapper allows to avoid cyclic include dependencies.
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>  arch/arm64/include/asm/memory.h |  2 +-
>  arch/arm64/include/asm/page.h   |  1 +
>  arch/arm64/kvm/mmu.c            |  2 +-
>  arch/arm64/mm/init.c            | 11 +++++++++++
>  arch/arm64/mm/ioremap.c         |  4 ++--
>  arch/arm64/mm/mmu.c             |  2 +-
>  6 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0aabc3be9a75..194f9f993d30 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>  
>  #define virt_addr_valid(addr)	({					\
>  	__typeof__(addr) __addr = __tag_reset(addr);			\
> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
>  })
>  
>  void dump_mem_limit(void);
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 012cffc574e8..99a6da91f870 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>  typedef struct page *pgtable_t;
>  
>  extern int pfn_valid(unsigned long);
> +extern int pfn_is_map_memory(unsigned long);

Check patch is complaining about this.

WARNING: function definition argument 'unsigned long' should also have an identifier name
#50: FILE: arch/arm64/include/asm/page.h:41:
+extern int pfn_is_map_memory(unsigned long);


>  
>  #include <asm/memory.h>
>  
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..23dd99e29b23 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>  
>  static bool kvm_is_device_pfn(unsigned long pfn)
>  {
> -	return !pfn_valid(pfn);
> +	return !pfn_is_map_memory(pfn);
>  }
>  
>  /*
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3685e12aba9b..dc03bdc12c0f 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
>  }
>  EXPORT_SYMBOL(pfn_valid);
>  
> +int pfn_is_map_memory(unsigned long pfn)
> +{
> +	phys_addr_t addr = PFN_PHYS(pfn);
> +

Should also bring with it, the comment regarding upper bits in
the pfn from arm64 pfn_valid().

> +	if (PHYS_PFN(addr) != pfn)
> +		return 0;
> +	

 ^^^^^ trailing spaces here.

ERROR: trailing whitespace
#81: FILE: arch/arm64/mm/init.c:263:
+^I$

> +	return memblock_is_map_memory(addr);
> +}
> +EXPORT_SYMBOL(pfn_is_map_memory);
> +

Is the EXPORT_SYMBOL() required to build drivers which will use
pfn_is_map_memory() but currently use pfn_valid() ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-21  6:51 ` [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
  2021-04-21  7:49   ` David Hildenbrand
@ 2021-04-21 11:06   ` Anshuman Khandual
  2021-04-21 12:24     ` Mike Rapoport
  1 sibling, 1 reply; 39+ messages in thread
From: Anshuman Khandual @ 2021-04-21 11:06 UTC (permalink / raw)
  To: Mike Rapoport, linux-arm-kernel
  Cc: Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm


On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
> 
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
> 
> * Parts of the memory map are freed during boot. This makes it necessary to
>   verify that there is actual physical memory that corresponds to a pfn
>   which is done by querying memblock.
> 
> * There are NOMAP memory regions. These regions are not mapped in the
>   linear map and until the previous commit the struct pages representing
>   these areas had default values.
> 
> As the consequence of absence of the special treatment of NOMAP regions in
> the memory map it was necessary to use memblock_is_map_memory() in
> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> generic mm functionality would not treat a NOMAP page as a normal page.
> 
> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> the rest of core mm will treat them as unusable memory and thus
> pfn_valid_within() is no longer required at all and can be disabled by
> removing CONFIG_HOLES_IN_ZONE on arm64.

This makes sense.

> 
> pfn_valid() can be slightly simplified by replacing
> memblock_is_map_memory() with memblock_is_memory().
> 
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>  arch/arm64/Kconfig   | 3 ---
>  arch/arm64/mm/init.c | 4 ++--
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e4e1b6550115..58e439046d05 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>  	def_bool y
>  	depends on NUMA
>  
> -config HOLES_IN_ZONE
> -	def_bool y
> -

Right.

>  source "kernel/Kconfig.hz"
>  
>  config ARCH_SPARSEMEM_ENABLE
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index dc03bdc12c0f..eb3f56fb8c7c 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>  
>  	/*
>  	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> +	 * memblock_is_memory() check for ZONE_DEVICE based
>  	 * addresses will always fail. Even the normal hotplugged
>  	 * memory will never have MEMBLOCK_NOMAP flag set in their
>  	 * memblock entries. Skip memblock search for all non early
> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>  		return pfn_section_valid(ms, pfn);
>  }
>  #endif
> -	return memblock_is_map_memory(addr);
> +	return memblock_is_memory(addr);

Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
memory pfns for page table walking purpose but with PageReserved(),
why memblock_is_memory() is still required ? At this point, should
not we just return valid for early_section() memory. As pfn_valid()
now just implies that pfn has a struct page backing which has been
already verified with valid_section() etc.

>  }
>  EXPORT_SYMBOL(pfn_valid);
>  
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid()
  2021-04-21 10:59   ` Anshuman Khandual
@ 2021-04-21 12:19     ` Mike Rapoport
  2021-04-21 13:13       ` Anshuman Khandual
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-21 12:19 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: linux-arm-kernel, Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm

On Wed, Apr 21, 2021 at 04:29:48PM +0530, Anshuman Khandual wrote:
> 
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> > 
> > The intended semantics of pfn_valid() is to verify whether there is a
> > struct page for the pfn in question and nothing else.
> > 
> > Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> > linear map vs those that require ioremap() to access them.
> > 
> > Introduce a dedicated pfn_is_map_memory() wrapper for
> > memblock_is_map_memory() to perform such check and use it where
> > appropriate.
> > 
> > Using a wrapper allows to avoid cyclic include dependencies.
> > 
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> >  arch/arm64/include/asm/memory.h |  2 +-
> >  arch/arm64/include/asm/page.h   |  1 +
> >  arch/arm64/kvm/mmu.c            |  2 +-
> >  arch/arm64/mm/init.c            | 11 +++++++++++
> >  arch/arm64/mm/ioremap.c         |  4 ++--
> >  arch/arm64/mm/mmu.c             |  2 +-
> >  6 files changed, 17 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 0aabc3be9a75..194f9f993d30 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> >  
> >  #define virt_addr_valid(addr)	({					\
> >  	__typeof__(addr) __addr = __tag_reset(addr);			\
> > -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> > +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
> >  })
> >  
> >  void dump_mem_limit(void);
> > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > index 012cffc574e8..99a6da91f870 100644
> > --- a/arch/arm64/include/asm/page.h
> > +++ b/arch/arm64/include/asm/page.h
> > @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
> >  typedef struct page *pgtable_t;
> >  
> >  extern int pfn_valid(unsigned long);
> > +extern int pfn_is_map_memory(unsigned long);
> 
> Check patch is complaining about this.
> 
> WARNING: function definition argument 'unsigned long' should also have an identifier name
> #50: FILE: arch/arm64/include/asm/page.h:41:
> +extern int pfn_is_map_memory(unsigned long);
> 
> 
> >  
> >  #include <asm/memory.h>
> >  
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 8711894db8c2..23dd99e29b23 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
> >  
> >  static bool kvm_is_device_pfn(unsigned long pfn)
> >  {
> > -	return !pfn_valid(pfn);
> > +	return !pfn_is_map_memory(pfn);
> >  }
> >  
> >  /*
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 3685e12aba9b..dc03bdc12c0f 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
> >  }
> >  EXPORT_SYMBOL(pfn_valid);
> >  
> > +int pfn_is_map_memory(unsigned long pfn)
> > +{
> > +	phys_addr_t addr = PFN_PHYS(pfn);
> > +
> 
> Should also bring with it, the comment regarding upper bits in
> the pfn from arm64 pfn_valid().

I think a reference to the comment in pfn_valid() will suffice.

BTW, I wonder how is that other architectures do not need this check?
 
> > +	if (PHYS_PFN(addr) != pfn)
> > +		return 0;
> > +	
> 
>  ^^^^^ trailing spaces here.
> 
> ERROR: trailing whitespace
> #81: FILE: arch/arm64/mm/init.c:263:
> +^I$

Oops :)
 
> > +	return memblock_is_map_memory(addr);
> > +}
> > +EXPORT_SYMBOL(pfn_is_map_memory);
> > +
> 
> Is the EXPORT_SYMBOL() required to build drivers which will use
> pfn_is_map_memory() but currently use pfn_valid() ?

Yes, this is required for virt_addr_valid() that is used by modules.

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-21 11:06   ` Anshuman Khandual
@ 2021-04-21 12:24     ` Mike Rapoport
  2021-04-21 13:15       ` Anshuman Khandual
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-21 12:24 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: linux-arm-kernel, Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm

On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
> 
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> > 
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> > 
> > * Parts of the memory map are freed during boot. This makes it necessary to
> >   verify that there is actual physical memory that corresponds to a pfn
> >   which is done by querying memblock.
> > 
> > * There are NOMAP memory regions. These regions are not mapped in the
> >   linear map and until the previous commit the struct pages representing
> >   these areas had default values.
> > 
> > As the consequence of absence of the special treatment of NOMAP regions in
> > the memory map it was necessary to use memblock_is_map_memory() in
> > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> > generic mm functionality would not treat a NOMAP page as a normal page.
> > 
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> > the rest of core mm will treat them as unusable memory and thus
> > pfn_valid_within() is no longer required at all and can be disabled by
> > removing CONFIG_HOLES_IN_ZONE on arm64.
> 
> This makes sense.
> 
> > 
> > pfn_valid() can be slightly simplified by replacing
> > memblock_is_map_memory() with memblock_is_memory().
> > 
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> >  arch/arm64/Kconfig   | 3 ---
> >  arch/arm64/mm/init.c | 4 ++--
> >  2 files changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e4e1b6550115..58e439046d05 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> >  	def_bool y
> >  	depends on NUMA
> >  
> > -config HOLES_IN_ZONE
> > -	def_bool y
> > -
> 
> Right.
> 
> >  source "kernel/Kconfig.hz"
> >  
> >  config ARCH_SPARSEMEM_ENABLE
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index dc03bdc12c0f..eb3f56fb8c7c 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
> >  
> >  	/*
> >  	 * ZONE_DEVICE memory does not have the memblock entries.
> > -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> > +	 * memblock_is_memory() check for ZONE_DEVICE based
> >  	 * addresses will always fail. Even the normal hotplugged
> >  	 * memory will never have MEMBLOCK_NOMAP flag set in their
> >  	 * memblock entries. Skip memblock search for all non early
> > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
> >  		return pfn_section_valid(ms, pfn);
> >  }
> >  #endif
> > -	return memblock_is_map_memory(addr);
> > +	return memblock_is_memory(addr);
> 
> Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
> memory pfns for page table walking purpose but with PageReserved(),
> why memblock_is_memory() is still required ? At this point, should
> not we just return valid for early_section() memory. As pfn_valid()
> now just implies that pfn has a struct page backing which has been
> already verified with valid_section() etc.

memblock_is_memory() is required because arm64 frees unused parts of the
memory map. So, for instance, if we have 64M out of 128M populated in a
section the section based calculation would return 1 for a pfn in the
second half of the section, but there would be no memory map there.


> >  }
> >  EXPORT_SYMBOL(pfn_valid);
> >  
> > 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid()
  2021-04-21 12:19     ` Mike Rapoport
@ 2021-04-21 13:13       ` Anshuman Khandual
  0 siblings, 0 replies; 39+ messages in thread
From: Anshuman Khandual @ 2021-04-21 13:13 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm

On 4/21/21 5:49 PM, Mike Rapoport wrote:
> On Wed, Apr 21, 2021 at 04:29:48PM +0530, Anshuman Khandual wrote:
>>
>> On 4/21/21 12:21 PM, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> The intended semantics of pfn_valid() is to verify whether there is a
>>> struct page for the pfn in question and nothing else.
>>>
>>> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
>>> linear map vs those that require ioremap() to access them.
>>>
>>> Introduce a dedicated pfn_is_map_memory() wrapper for
>>> memblock_is_map_memory() to perform such check and use it where
>>> appropriate.
>>>
>>> Using a wrapper allows to avoid cyclic include dependencies.
>>>
>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>>> ---
>>>  arch/arm64/include/asm/memory.h |  2 +-
>>>  arch/arm64/include/asm/page.h   |  1 +
>>>  arch/arm64/kvm/mmu.c            |  2 +-
>>>  arch/arm64/mm/init.c            | 11 +++++++++++
>>>  arch/arm64/mm/ioremap.c         |  4 ++--
>>>  arch/arm64/mm/mmu.c             |  2 +-
>>>  6 files changed, 17 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>> index 0aabc3be9a75..194f9f993d30 100644
>>> --- a/arch/arm64/include/asm/memory.h
>>> +++ b/arch/arm64/include/asm/memory.h
>>> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>>  
>>>  #define virt_addr_valid(addr)	({					\
>>>  	__typeof__(addr) __addr = __tag_reset(addr);			\
>>> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
>>> +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
>>>  })
>>>  
>>>  void dump_mem_limit(void);
>>> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
>>> index 012cffc574e8..99a6da91f870 100644
>>> --- a/arch/arm64/include/asm/page.h
>>> +++ b/arch/arm64/include/asm/page.h
>>> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>>>  typedef struct page *pgtable_t;
>>>  
>>>  extern int pfn_valid(unsigned long);
>>> +extern int pfn_is_map_memory(unsigned long);
>>
>> Check patch is complaining about this.
>>
>> WARNING: function definition argument 'unsigned long' should also have an identifier name
>> #50: FILE: arch/arm64/include/asm/page.h:41:
>> +extern int pfn_is_map_memory(unsigned long);
>>
>>
>>>  
>>>  #include <asm/memory.h>
>>>  
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 8711894db8c2..23dd99e29b23 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>>>  
>>>  static bool kvm_is_device_pfn(unsigned long pfn)
>>>  {
>>> -	return !pfn_valid(pfn);
>>> +	return !pfn_is_map_memory(pfn);
>>>  }
>>>  
>>>  /*
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 3685e12aba9b..dc03bdc12c0f 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
>>>  }
>>>  EXPORT_SYMBOL(pfn_valid);
>>>  
>>> +int pfn_is_map_memory(unsigned long pfn)
>>> +{
>>> +	phys_addr_t addr = PFN_PHYS(pfn);
>>> +
>>
>> Should also bring with it, the comment regarding upper bits in
>> the pfn from arm64 pfn_valid().
> 
> I think a reference to the comment in pfn_valid() will suffice.

Okay.

> 
> BTW, I wonder how is that other architectures do not need this check?

Trying to move that into generic pfn_valid() in mmzone.h, will resend
the RFC patch after this series.

https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual@arm.com/

>  
>>> +	if (PHYS_PFN(addr) != pfn)
>>> +		return 0;
>>> +	
>>
>>  ^^^^^ trailing spaces here.
>>
>> ERROR: trailing whitespace
>> #81: FILE: arch/arm64/mm/init.c:263:
>> +^I$
> 
> Oops :)
>  
>>> +	return memblock_is_map_memory(addr);
>>> +}
>>> +EXPORT_SYMBOL(pfn_is_map_memory);
>>> +
>>
>> Is the EXPORT_SYMBOL() required to build drivers which will use
>> pfn_is_map_memory() but currently use pfn_valid() ?
> 
> Yes, this is required for virt_addr_valid() that is used by modules.
> 

There will be two adjacent EXPORT_SYMBOLS(), one for pfn_valid() and
one for pfn_is_map_memory(). But its okay I guess, cant help it.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-21 12:24     ` Mike Rapoport
@ 2021-04-21 13:15       ` Anshuman Khandual
  0 siblings, 0 replies; 39+ messages in thread
From: Anshuman Khandual @ 2021-04-21 13:15 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Ard Biesheuvel, Catalin Marinas,
	David Hildenbrand, Marc Zyngier, Mark Rutland, Mike Rapoport,
	Will Deacon, kvmarm, linux-kernel, linux-mm



On 4/21/21 5:54 PM, Mike Rapoport wrote:
> On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
>>
>> On 4/21/21 12:21 PM, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> The arm64's version of pfn_valid() differs from the generic because of two
>>> reasons:
>>>
>>> * Parts of the memory map are freed during boot. This makes it necessary to
>>>   verify that there is actual physical memory that corresponds to a pfn
>>>   which is done by querying memblock.
>>>
>>> * There are NOMAP memory regions. These regions are not mapped in the
>>>   linear map and until the previous commit the struct pages representing
>>>   these areas had default values.
>>>
>>> As the consequence of absence of the special treatment of NOMAP regions in
>>> the memory map it was necessary to use memblock_is_map_memory() in
>>> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
>>> generic mm functionality would not treat a NOMAP page as a normal page.
>>>
>>> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
>>> the rest of core mm will treat them as unusable memory and thus
>>> pfn_valid_within() is no longer required at all and can be disabled by
>>> removing CONFIG_HOLES_IN_ZONE on arm64.
>>
>> This makes sense.
>>
>>>
>>> pfn_valid() can be slightly simplified by replacing
>>> memblock_is_map_memory() with memblock_is_memory().
>>>
>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>>> ---
>>>  arch/arm64/Kconfig   | 3 ---
>>>  arch/arm64/mm/init.c | 4 ++--
>>>  2 files changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index e4e1b6550115..58e439046d05 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>>>  	def_bool y
>>>  	depends on NUMA
>>>  
>>> -config HOLES_IN_ZONE
>>> -	def_bool y
>>> -
>>
>> Right.
>>
>>>  source "kernel/Kconfig.hz"
>>>  
>>>  config ARCH_SPARSEMEM_ENABLE
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index dc03bdc12c0f..eb3f56fb8c7c 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>>>  
>>>  	/*
>>>  	 * ZONE_DEVICE memory does not have the memblock entries.
>>> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
>>> +	 * memblock_is_memory() check for ZONE_DEVICE based
>>>  	 * addresses will always fail. Even the normal hotplugged
>>>  	 * memory will never have MEMBLOCK_NOMAP flag set in their
>>>  	 * memblock entries. Skip memblock search for all non early
>>> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>>>  		return pfn_section_valid(ms, pfn);
>>>  }
>>>  #endif
>>> -	return memblock_is_map_memory(addr);
>>> +	return memblock_is_memory(addr);
>>
>> Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
>> memory pfns for page table walking purpose but with PageReserved(),
>> why memblock_is_memory() is still required ? At this point, should
>> not we just return valid for early_section() memory. As pfn_valid()
>> now just implies that pfn has a struct page backing which has been
>> already verified with valid_section() etc.
> 
> memblock_is_memory() is required because arm64 frees unused parts of the
> memory map. So, for instance, if we have 64M out of 128M populated in a
> section the section based calculation would return 1 for a pfn in the
> second half of the section, but there would be no memory map there.

Understood.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-21  6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
                   ` (3 preceding siblings ...)
  2021-04-21  6:51 ` [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
@ 2021-04-22  7:00 ` Kefeng Wang
  2021-04-22  7:29   ` Mike Rapoport
  4 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-04-22  7:00 UTC (permalink / raw)
  To: Mike Rapoport, linux-arm-kernel
  Cc: Andrew Morton, Anshuman Khandual, Ard Biesheuvel,
	Catalin Marinas, David Hildenbrand, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Will Deacon, kvmarm, linux-kernel, linux-mm


On 2021/4/21 14:51, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> Hi,
>
> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> pfn_valid_within() to 1.
>
> The idea is to mark NOMAP pages as reserved in the memory map and restore
> the intended semantics of pfn_valid() to designate availability of struct
> page for a pfn.
>
> With this the core mm will be able to cope with the fact that it cannot use
> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> will be treated correctly even without the need for pfn_valid_within.
>
> The patches are only boot tested on qemu-system-aarch64 so I'd really
> appreciate memory stress tests on real hardware.
>
> If this actually works we'll be one step closer to drop custom pfn_valid()
> on arm64 altogether.

Hi Mike,I have a question, without HOLES_IN_ZONE, the pfn_valid_within() 
in move_freepages_block()->move_freepages()
will be optimized, if there are holes in zone, the 'struce page'(memory 
map) for pfn range of hole will be free by
free_memmap(), and then the page traverse in the zone(with holes) from 
move_freepages() will meet the wrong page,
then it could panic at PageLRU(page) test, check link[1],

"The idea is to mark NOMAP pages as reserved in the memory map", I see 
the patch2 check memblock_is_nomap() in memory region
of memblock, but it seems that memblock_mark_nomap() is not called(maybe 
I missed), then memmap_init_reserved_pages() won't
work, so should the HOLES_IN_ZONE still be needed for generic mm code?

[1] 
https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047@arm.com/


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-22  7:00 ` [PATCH v2 0/4] " Kefeng Wang
@ 2021-04-22  7:29   ` Mike Rapoport
  2021-04-22 15:28     ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-22  7:29 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/21 14:51, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> > 
> > Hi,
> > 
> > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> > pfn_valid_within() to 1.
> > 
> > The idea is to mark NOMAP pages as reserved in the memory map and restore
> > the intended semantics of pfn_valid() to designate availability of struct
> > page for a pfn.
> > 
> > With this the core mm will be able to cope with the fact that it cannot use
> > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> > will be treated correctly even without the need for pfn_valid_within.
> > 
> > The patches are only boot tested on qemu-system-aarch64 so I'd really
> > appreciate memory stress tests on real hardware.
> > 
> > If this actually works we'll be one step closer to drop custom pfn_valid()
> > on arm64 altogether.
> 
> Hi Mike,I have a question, without HOLES_IN_ZONE, the pfn_valid_within() in
> move_freepages_block()->move_freepages()
> will be optimized, if there are holes in zone, the 'struce page'(memory map)
> for pfn range of hole will be free by
> free_memmap(), and then the page traverse in the zone(with holes) from
> move_freepages() will meet the wrong page,
> then it could panic at PageLRU(page) test, check link[1],

First, HOLES_IN_ZONE name us hugely misleading, this configuration option
has nothing to to with memory holes, but rather it is there to deal with
holes or undefined struct pages in the memory map, when these holes can be
inside a MAX_ORDER_NR_PAGES region.

In general pfn walkers use pfn_valid() and pfn_valid_within() to avoid
accessing *missing* struct pages, like those that are freed at
free_memmap(). But on arm64 these tests also filter out the nomap entries
because their struct pages are not initialized.

The panic you refer to happened because there was an uninitialized struct
page in the middle of MAX_ORDER_NR_PAGES region because it corresponded to
nomap memory.

With these changes I make sure that such pages will be properly initialized
as PageReserved and the pfn walkers will be able to rely on the memory map.

Note also, that free_memmap() aligns the parts being freed on MAX_ORDER
boundaries, so there will be no missing parts in the memory map within a
MAX_ORDER_NR_PAGES region.
 
> "The idea is to mark NOMAP pages as reserved in the memory map", I see the
> patch2 check memblock_is_nomap() in memory region
> of memblock, but it seems that memblock_mark_nomap() is not called(maybe I
> missed), then memmap_init_reserved_pages() won't
> work, so should the HOLES_IN_ZONE still be needed for generic mm code?
> 
> [1] https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047@arm.com/
> 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-22  7:29   ` Mike Rapoport
@ 2021-04-22 15:28     ` Kefeng Wang
  2021-04-23  8:11       ` Kefeng Wang
  2021-04-25  6:59       ` [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
  0 siblings, 2 replies; 39+ messages in thread
From: Kefeng Wang @ 2021-04-22 15:28 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm


On 2021/4/22 15:29, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
>> On 2021/4/21 14:51, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> Hi,
>>>
>>> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
>>> pfn_valid_within() to 1.
>>>
>>> The idea is to mark NOMAP pages as reserved in the memory map and restore
>>> the intended semantics of pfn_valid() to designate availability of struct
>>> page for a pfn.
>>>
>>> With this the core mm will be able to cope with the fact that it cannot use
>>> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
>>> will be treated correctly even without the need for pfn_valid_within.
>>>
>>> The patches are only boot tested on qemu-system-aarch64 so I'd really
>>> appreciate memory stress tests on real hardware.
>>>
>>> If this actually works we'll be one step closer to drop custom pfn_valid()
>>> on arm64 altogether.
>> Hi Mike,I have a question, without HOLES_IN_ZONE, the pfn_valid_within() in
>> move_freepages_block()->move_freepages()
>> will be optimized, if there are holes in zone, the 'struce page'(memory map)
>> for pfn range of hole will be free by
>> free_memmap(), and then the page traverse in the zone(with holes) from
>> move_freepages() will meet the wrong page,
>> then it could panic at PageLRU(page) test, check link[1],
> First, HOLES_IN_ZONE name us hugely misleading, this configuration option
> has nothing to to with memory holes, but rather it is there to deal with
> holes or undefined struct pages in the memory map, when these holes can be
> inside a MAX_ORDER_NR_PAGES region.
>
> In general pfn walkers use pfn_valid() and pfn_valid_within() to avoid
> accessing *missing* struct pages, like those that are freed at
> free_memmap(). But on arm64 these tests also filter out the nomap entries
> because their struct pages are not initialized.
>
> The panic you refer to happened because there was an uninitialized struct
> page in the middle of MAX_ORDER_NR_PAGES region because it corresponded to
> nomap memory.
>
> With these changes I make sure that such pages will be properly initialized
> as PageReserved and the pfn walkers will be able to rely on the memory map.
>
> Note also, that free_memmap() aligns the parts being freed on MAX_ORDER
> boundaries, so there will be no missing parts in the memory map within a
> MAX_ORDER_NR_PAGES region.

Ok, thanks, we met a same panic like the link on arm32(without 
HOLES_IN_ZONE),

the scheme for arm64 could be suit for arm32, right?  I will try the 
patchset with

some changes on arm32 and give some feedback.

Again, the stupid question, where will mark the region of memblock with

MEMBLOCK_NOMAP flag ?


>   
>> "The idea is to mark NOMAP pages as reserved in the memory map", I see the
>> patch2 check memblock_is_nomap() in memory region
>> of memblock, but it seems that memblock_mark_nomap() is not called(maybe I
>> missed), then memmap_init_reserved_pages() won't
>> work, so should the HOLES_IN_ZONE still be needed for generic mm code?
>>
>> [1] https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047@arm.com/
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-22 15:28     ` Kefeng Wang
@ 2021-04-23  8:11       ` Kefeng Wang
  2021-04-25  7:19         ` arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()) Mike Rapoport
  2021-04-25  6:59       ` [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
  1 sibling, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-04-23  8:11 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm


On 2021/4/22 23:28, Kefeng Wang wrote:
>
> On 2021/4/22 15:29, Mike Rapoport wrote:
>> On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
>>> On 2021/4/21 14:51, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>>
>>>> Hi,
>>>>
>>>> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially 
>>>> hardwire
>>>> pfn_valid_within() to 1.
>>>>
>>>> The idea is to mark NOMAP pages as reserved in the memory map and 
>>>> restore
>>>> the intended semantics of pfn_valid() to designate availability of 
>>>> struct
>>>> page for a pfn.
>>>>
>>>> With this the core mm will be able to cope with the fact that it 
>>>> cannot use
>>>> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER 
>>>> blocks
>>>> will be treated correctly even without the need for pfn_valid_within.
>>>>
>>>> The patches are only boot tested on qemu-system-aarch64 so I'd really
>>>> appreciate memory stress tests on real hardware.
>>>>
>>>> If this actually works we'll be one step closer to drop custom 
>>>> pfn_valid()
>>>> on arm64 altogether.
...
>
> Ok, thanks, we met a same panic like the link on arm32(without 
> HOLES_IN_ZONE),
>
> the scheme for arm64 could be suit for arm32, right?  I will try the 
> patchset with
>
> some changes on arm32 and give some feedback.

I tested this patchset(plus arm32 change, like arm64 does) based on lts 
5.10,add

some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, 
no panic,

any idea, thanks.

Zone ranges:
   Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
   HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
Movable zone start for each node
Early memory node ranges
   node   0: [mem 0x0000000080a00000-0x00000000855fffff]
   node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
   node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
   node   0: [mem 0x000000008e300000-0x000000008ecfffff]
   node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
   node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
   node   0: [mem 0x00000000de700000-0x00000000de9fffff]
   node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
   node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
   node   0: [mem 0x00000000fda00000-0x00000000ffffefff]

----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86a00, 86a00000
----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e300, 8e300000
----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700, de700000
----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000
=== >move_freepages: start_pfn/end_pfn [de600, de7ff], [de600000, 
de7ff000] :  pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags 
= ffffffff
8<--- cut here ---
Unable to handle kernel paging request at virtual address fffffffe
pgd = 5dd50df5
[fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
Internal error: Oops: 37 [#1] SMP ARM
Modules linked in: gmac(O)
CPU: 2 PID: 635 Comm: test-oom Tainted: G           O      5.10.0+ #31
Hardware name: Hisilicon A9
PC is at move_freepages_block+0x150/0x278
LR is at move_freepages_block+0x150/0x278
pc : [<c02383a4>]    lr : [<c02383a4>]    psr: 200e0393
sp : c4179cf8  ip : 00000000  fp : 00000001
r10: c4179d58  r9 : 000de7ff  r8 : 00000000
r7 : c0863280  r6 : 000de600  r5 : 000de600  r4 : ef3cc000
r3 : ffffffff  r2 : 00000000  r1 : ef5d069c  r0 : fffffffe
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 1ac5387d  Table: 83b0c04a  DAC: 55555555
Process test-oom (pid: 635, stack limit = 0x25d667df)


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
  2021-04-22 15:28     ` Kefeng Wang
  2021-04-23  8:11       ` Kefeng Wang
@ 2021-04-25  6:59       ` Mike Rapoport
  1 sibling, 0 replies; 39+ messages in thread
From: Mike Rapoport @ 2021-04-25  6:59 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Thu, Apr 22, 2021 at 11:28:24PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/22 15:29, Mike Rapoport wrote:
> > On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
> > > On 2021/4/21 14:51, Mike Rapoport wrote:
> > > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > > 
> > > > Hi,
> > > > 
> > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> > > > pfn_valid_within() to 1.
> > > > 
> > > > The idea is to mark NOMAP pages as reserved in the memory map and restore
> > > > the intended semantics of pfn_valid() to designate availability of struct
> > > > page for a pfn.
> > > > 
> > > > With this the core mm will be able to cope with the fact that it cannot use
> > > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> > > > will be treated correctly even without the need for pfn_valid_within.
> > > > 
> > > > The patches are only boot tested on qemu-system-aarch64 so I'd really
> > > > appreciate memory stress tests on real hardware.
> > > > 
> > > > If this actually works we'll be one step closer to drop custom pfn_valid()
> > > > on arm64 altogether.
> > > Hi Mike,I have a question, without HOLES_IN_ZONE, the pfn_valid_within() in
> > > move_freepages_block()->move_freepages()
> > > will be optimized, if there are holes in zone, the 'struce page'(memory map)
> > > for pfn range of hole will be free by
> > > free_memmap(), and then the page traverse in the zone(with holes) from
> > > move_freepages() will meet the wrong page,
> > > then it could panic at PageLRU(page) test, check link[1],
> > First, HOLES_IN_ZONE name us hugely misleading, this configuration option
> > has nothing to to with memory holes, but rather it is there to deal with
> > holes or undefined struct pages in the memory map, when these holes can be
> > inside a MAX_ORDER_NR_PAGES region.
> > 
> > In general pfn walkers use pfn_valid() and pfn_valid_within() to avoid
> > accessing *missing* struct pages, like those that are freed at
> > free_memmap(). But on arm64 these tests also filter out the nomap entries
> > because their struct pages are not initialized.
> > 
> > The panic you refer to happened because there was an uninitialized struct
> > page in the middle of MAX_ORDER_NR_PAGES region because it corresponded to
> > nomap memory.
> > 
> > With these changes I make sure that such pages will be properly initialized
> > as PageReserved and the pfn walkers will be able to rely on the memory map.
> > 
> > Note also, that free_memmap() aligns the parts being freed on MAX_ORDER
> > boundaries, so there will be no missing parts in the memory map within a
> > MAX_ORDER_NR_PAGES region.
> 
> Ok, thanks, we met a same panic like the link on arm32(without
> HOLES_IN_ZONE),
> 
> the scheme for arm64 could be suit for arm32, right?

In general yes. You just need to make sure that usage of pfn_valid() in
arch/arm does not presume that it tests something beyond availability of
struct page for a pfn.
 
> I will try the patchset with some changes on arm32 and give some
> feedback.
> 
> Again, the stupid question, where will mark the region of memblock with
> MEMBLOCK_NOMAP flag ?
 
Not sure I understand the question. The memory regions with "nomap"
property in the device tree will be marked MEMBLOCK_NOMAP.
 
> > > "The idea is to mark NOMAP pages as reserved in the memory map", I see the
> > > patch2 check memblock_is_nomap() in memory region
> > > of memblock, but it seems that memblock_mark_nomap() is not called(maybe I
> > > missed), then memmap_init_reserved_pages() won't
> > > work, so should the HOLES_IN_ZONE still be needed for generic mm code?
> > > 
> > > [1] https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047@arm.com/
> > > 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-23  8:11       ` Kefeng Wang
@ 2021-04-25  7:19         ` Mike Rapoport
       [not found]           ` <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-25  7:19 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> 
> I tested this patchset(plus arm32 change, like arm64 does) based on lts
> 5.10,add
> 
> some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, no
> panic,
> 
> any idea, thanks.
 
Are there any changes on top of 5.10 except for pfn_valid() patch?
Do you see this panic on 5.10 without the changes?
Can you see stack backtrace beyond move_freepages_block?

> Zone ranges:
>   Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
>   HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x0000000080a00000-0x00000000855fffff]
>   node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
>   node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
>   node   0: [mem 0x000000008e300000-0x000000008ecfffff]
>   node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
>   node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>   node   0: [mem 0x00000000de700000-0x00000000de9fffff]
>   node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>   node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>   node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
> 
> ----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86a00, 86a00000
> ----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e300, 8e300000
> ----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
> ----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700, de700000
> ----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
> ----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
> ----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000
> === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
> :  pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address fffffffe
> pgd = 5dd50df5
> [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
> Internal error: Oops: 37 [#1] SMP ARM
> Modules linked in: gmac(O)
> CPU: 2 PID: 635 Comm: test-oom Tainted: G           O      5.10.0+ #31
> Hardware name: Hisilicon A9
> PC is at move_freepages_block+0x150/0x278
> LR is at move_freepages_block+0x150/0x278
> pc : [<c02383a4>]    lr : [<c02383a4>]    psr: 200e0393
> sp : c4179cf8  ip : 00000000  fp : 00000001
> r10: c4179d58  r9 : 000de7ff  r8 : 00000000
> r7 : c0863280  r6 : 000de600  r5 : 000de600  r4 : ef3cc000
> r3 : ffffffff  r2 : 00000000  r1 : ef5d069c  r0 : fffffffe
> Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 1ac5387d  Table: 83b0c04a  DAC: 55555555
> Process test-oom (pid: 635, stack limit = 0x25d667df)
> 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
       [not found]           ` <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
@ 2021-04-26  5:20             ` Mike Rapoport
  2021-04-26 15:26               ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-26  5:20 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/25 15:19, Mike Rapoport wrote:
> 
>     On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> 
>         I tested this patchset(plus arm32 change, like arm64 does) based on lts
>         5.10,add
> 
>         some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, no
>         panic,
> 
>         any idea, thanks.
> 
> 
>     Are there any changes on top of 5.10 except for pfn_valid() patch?
>     Do you see this panic on 5.10 without the changes?
> 
> Yes, there are some BSP support for arm board based on 5.10, with or without
> 
> your patch will get same panic, the panic pfn=de600 in the range of
> [dcc00,de00]
> 
> which is freed by free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700,
> de700000
> 
> we see the PC is at PageLRU, same reason like arm64 panic log,
> 
>    "PageBuddy in move_freepages returns false
>     Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
>     compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
>     resturns 0xfffffffffffffffe - and accessing this address causes crash"
> 
>     Can you see stack backtrace beyond move_freepages_block?
> 
> I do some oom test, so the log is about memory allocate,
> 
> [<c02383c8>] (move_freepages_block) from [<c0238668>]
> (steal_suitable_fallback+0x174/0x1f4)
> 
> [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)

Hmm, this is called with a page from free list, having a page from a freed
part of the memory map passed to steal_suitable_fallback() means that there
is an issue with creation of the free list.

Can you please add "memblock=debug" to the kernel command line and post the
log?

> [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
> [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
> [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
> [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
> [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
> [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
> 
> 
> 
>         Zone ranges:
>           Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
>           HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
>         Movable zone start for each node
>         Early memory node ranges
>           node   0: [mem 0x0000000080a00000-0x00000000855fffff]
>           node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
>           node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
>           node   0: [mem 0x000000008e300000-0x000000008ecfffff]
>           node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
>           node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>           node   0: [mem 0x00000000de700000-0x00000000de9fffff]
>           node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>           node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>           node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
> 
>         ----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86a00, 86a00000
>         ----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e300, 8e300000
>         ----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
>         ----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700, de700000
>         ----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
>         ----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
>         ----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000
>         === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
>         :  pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
>         8<--- cut here ---
>         Unable to handle kernel paging request at virtual address fffffffe
>         pgd = 5dd50df5
>         [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
>         Internal error: Oops: 37 [#1] SMP ARM
>         Modules linked in: gmac(O)
>         CPU: 2 PID: 635 Comm: test-oom Tainted: G           O      5.10.0+ #31
>         Hardware name: Hisilicon A9
>         PC is at move_freepages_block+0x150/0x278
>         LR is at move_freepages_block+0x150/0x278
>         pc : [<c02383a4>]    lr : [<c02383a4>]    psr: 200e0393
>         sp : c4179cf8  ip : 00000000  fp : 00000001
>         r10: c4179d58  r9 : 000de7ff  r8 : 00000000
>         r7 : c0863280  r6 : 000de600  r5 : 000de600  r4 : ef3cc000
>         r3 : ffffffff  r2 : 00000000  r1 : ef5d069c  r0 : fffffffe
>         Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
>         Control: 1ac5387d  Table: 83b0c04a  DAC: 55555555
>         Process test-oom (pid: 635, stack limit = 0x25d667df)
> 
> 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-26  5:20             ` Mike Rapoport
@ 2021-04-26 15:26               ` Kefeng Wang
  2021-04-27  6:23                 ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-04-26 15:26 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm


On 2021/4/26 13:20, Mike Rapoport wrote:
> On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
>> On 2021/4/25 15:19, Mike Rapoport wrote:
>>
>>      On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
>>
>>          I tested this patchset(plus arm32 change, like arm64 does) based on lts
>>          5.10,add
>>
>>          some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, no
>>          panic,
>>
>>          any idea, thanks.
>>
>>
>>      Are there any changes on top of 5.10 except for pfn_valid() patch?
>>      Do you see this panic on 5.10 without the changes?
>>
>> Yes, there are some BSP support for arm board based on 5.10, with or without
>>
>> your patch will get same panic, the panic pfn=de600 in the range of
>> [dcc00,de00]
>>
>> which is freed by free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700,
>> de700000
>>
>> we see the PC is at PageLRU, same reason like arm64 panic log,
>>
>>     "PageBuddy in move_freepages returns false
>>      Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
>>      compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
>>      resturns 0xfffffffffffffffe - and accessing this address causes crash"
>>
>>      Can you see stack backtrace beyond move_freepages_block?
>>
>> I do some oom test, so the log is about memory allocate,
>>
>> [<c02383c8>] (move_freepages_block) from [<c0238668>]
>> (steal_suitable_fallback+0x174/0x1f4)
>>
>> [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)
> Hmm, this is called with a page from free list, having a page from a freed
> part of the memory map passed to steal_suitable_fallback() means that there
> is an issue with creation of the free list.
>
> Can you please add "memblock=debug" to the kernel command line and post the
> log?

Here is the log,

CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=1ac5387d

CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: HISI-CA9
memblock_add: [0x80a00000-0x855fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x86a00000-0x87dfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x8bd00000-0x8c4fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x8e300000-0x8ecfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x90d00000-0xbfffffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xcc000000-0xdc9fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xe0800000-0xe0bfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xf5300000-0xf5bfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xf5c00000-0xf6ffffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xfe100000-0xfebfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xfec00000-0xffffffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xde700000-0xde9fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xf4b00000-0xf52fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xfda00000-0xfe0fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_reserve: [0x80a01000-0x80a02d2e] setup_arch+0x68/0x5c4
Malformed early option 'vecpage_wrprotect'
Memory policy: Data cache writealloc
memblock_reserve: [0x80b00000-0x812e8057] arm_memblock_init+0x34/0x14c
memblock_reserve: [0x83000000-0x84ffffff] arm_memblock_init+0x100/0x14c
memblock_reserve: [0x80a04000-0x80a07fff] arm_memblock_init+0xa0/0x14c
memblock_reserve: [0x80a00000-0x80a02fff] hisi_mem_reserve+0x14/0x30
MEMBLOCK configuration:
  memory size = 0x4c0fffff reserved size = 0x027ef058
  memory.cnt  = 0xa
  memory[0x0]    [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
  memory[0x1]    [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
  memory[0x2]    [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
  memory[0x3]    [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
  memory[0x4]    [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
  memory[0x5]    [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
  memory[0x6]    [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
  memory[0x7]    [0xe0800000-0xe0bfffff], 0x00400000 bytes flags: 0x0
  memory[0x8]    [0xf4b00000-0xf6ffffff], 0x02500000 bytes flags: 0x0
  memory[0x9]    [0xfda00000-0xfffffffe], 0x025fffff bytes flags: 0x0
  reserved.cnt  = 0x4
  reserved[0x0]    [0x80a00000-0x80a02fff], 0x00003000 bytes flags: 0x0
  reserved[0x1]    [0x80a04000-0x80a07fff], 0x00004000 bytes flags: 0x0
  reserved[0x2]    [0x80b00000-0x812e8057], 0x007e8058 bytes flags: 0x0
  reserved[0x3]    [0x83000000-0x84ffffff], 0x02000000 bytes flags: 0x0
memblock_alloc_try_nid: 2097152 bytes align=0x200000 nid=-1 
from=0x00000000 max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xb0000000-0xb01fffff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xaffff000-0xafffffff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 40 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 iotable_init+0x34/0xf0
memblock_reserve: [0xafffefd8-0xafffefff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffd000-0xafffdfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffc000-0xafffcfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffb000-0xafffbfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffa000-0xafffafff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 384 bytes align=0x20 nid=0 from=0x00000000 
max_addr=0x00000000 sparse_init_nid+0x34/0x1d8
memblock_reserve: [0xafffee40-0xafffefbf] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_exact_nid_raw: 12582912 bytes align=0x80000 nid=0 
from=0xc09fffff max_addr=0x00000000 sparse_init_nid+0xec/0x1d8
memblock_reserve: [0xaf380000-0xaff7ffff] 
memblock_alloc_range_nid+0x104/0x13c
Zone ranges:
   Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
   HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
Movable zone start for each node
Early memory node ranges
   node   0: [mem 0x0000000080a00000-0x00000000855fffff]
   node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
   node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
   node   0: [mem 0x000000008e300000-0x000000008ecfffff]
   node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
   node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
   node   0: [mem 0x00000000de700000-0x00000000de9fffff]
   node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
   node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
   node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
Zeroed struct page in unavailable ranges: 513 pages
Initmem setup node 0 [mem 0x0000000080a00000-0x00000000ffffefff]
On node 0 totalpages: 311551
   Normal zone: 1230 pages used for memmap
   Normal zone: 0 pages reserved
   Normal zone: 157440 pages, LIFO batch:31
   HighMem zone: 154111 pages, LIFO batch:31
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffee20-0xafffee3f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffee00-0xafffee1f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffede0-0xafffedff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffedc0-0xafffeddf] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffeda0-0xafffedbf] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed80-0xafffed9f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed60-0xafffed7f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed40-0xafffed5f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed20-0xafffed3f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed00-0xafffed1f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 22396 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 early_init_dt_alloc_memory_arch+0x30/0x64
memblock_reserve: [0xafff4884-0xafff9fff] 
memblock_alloc_range_nid+0x104/0x13c
[dts]:cpu type is 1380
memblock_alloc_try_nid: 404 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc.constprop.8+0x1c/0x24
memblock_reserve: [0xafffeb60-0xafffecf3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 404 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc.constprop.8+0x1c/0x24
memblock_reserve: [0xafffe9c0-0xafffeb53] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafff3000-0xafff3fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafff2000-0xafff2fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 278528 bytes align=0x1000 nid=-1 from=0xc09fffff 
max_addr=0x00000000 pcpu_dfl_fc_alloc+0x28/0x34
memblock_reserve: [0xaffae000-0xafff1fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_free: [0xaffbf000-0xaffbefff] pcpu_embed_first_chunk+0x5ec/0x6a8
memblock_free: [0xaffd0000-0xaffcffff] pcpu_embed_first_chunk+0x5ec/0x6a8
memblock_free: [0xaffe1000-0xaffe0fff] pcpu_embed_first_chunk+0x5ec/0x6a8
memblock_free: [0xafff2000-0xafff1fff] pcpu_embed_first_chunk+0x5ec/0x6a8
percpu: Embedded 17 pages/cpu s37044 r8192 d24396 u69632
memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffefc0-0xafffefc3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe9a0-0xafffe9a3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 16 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe980-0xafffe98f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 16 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe960-0xafffe96f] 
memblock_alloc_range_nid+0x104/0x13c
pcpu-alloc: s37044 r8192 d24396 u69632 alloc=17*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
memblock_alloc_try_nid: 128 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe8e0-0xafffe95f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 92 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe880-0xafffe8db] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 384 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe700-0xafffe87f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 388 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe560-0xafffe6e3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe500-0xafffe55f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 92 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe4a0-0xafffe4fb] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 768 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe1a0-0xafffe49f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 772 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafff4580-0xafff4883] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 192 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe0e0-0xafffe19f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_free: [0xafff3000-0xafff3fff] pcpu_embed_first_chunk+0x570/0x6a8
memblock_free: [0xafff2000-0xafff2fff] pcpu_embed_first_chunk+0x58c/0x6a8
Built 1 zonelists, mobility grouping on.  Total pages: 310321
Kernel command line: console=ttyAMA0,9600n8N lpj=8000000 
initrd=0x83000000,0x2000000 maxcpus=4 master_cpu=1 quiet highres=off  
oops=panic vecpage_wrprotect ksm=1 ramdisk_size=30720 kmemleak=off 
min_loop=128 lockd.nlm_tcpport=13001 lockd.nlm_udpport=13001 
rdinit=/sbin/init root=/dev/ram0 vmalloc=256M
printk: log_buf_len individual max cpu contribution: 4096 bytes
printk: log_buf_len total cpu_extra contributions: 12288 bytes
printk: log_buf_len min size: 16384 bytes
memblock_alloc_try_nid: 32768 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_log_buf+0xe4/0x404
memblock_reserve: [0xaffa6000-0xaffadfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 12288 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_log_buf+0x130/0x404
memblock_reserve: [0xaffa3000-0xaffa5fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 90112 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_log_buf+0x180/0x404
memblock_reserve: [0xaff8d000-0xaffa2fff] 
memblock_alloc_range_nid+0x104/0x13c
printk: log_buf_len: 32768 bytes
printk: early log buf free: 2492(15%)
memblock_alloc_try_nid: 524288 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 alloc_large_system_hash+0x1b0/0x2e8
memblock_reserve: [0xaf300000-0xaf37ffff] 
memblock_alloc_range_nid+0x104/0x13c
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
memblock_alloc_try_nid: 262144 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 alloc_large_system_hash+0x1b0/0x2e8
memblock_reserve: [0xaf2c0000-0xaf2fffff] 
memblock_alloc_range_nid+0x104/0x13c
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
memblock_free: [0xaf430000-0xaf453fff] mem_init+0x154/0x238
memblock_free: [0xaf510000-0xaf545fff] mem_init+0x154/0x238
memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x154/0x238
memblock_free: [0xafd98000-0xafdcdfff] mem_init+0x154/0x238
memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x154/0x238
memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x154/0x238
memblock_free: [0xafee0000-0xafefffff] mem_init+0x154/0x238
Memory: 1191160K/1246204K available (4096K kernel code, 436K rwdata, 
1120K rodata, 1024K init, 491K bss, 55044K reserved, 0K cma-reserved, 
616444K highmem)

>> [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
>> [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
>> [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
>> [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
>> [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
>> [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
>>
>>
>>
>>          Zone ranges:
>>            Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
>>            HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
>>          Movable zone start for each node
>>          Early memory node ranges
>>            node   0: [mem 0x0000000080a00000-0x00000000855fffff]
>>            node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
>>            node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
>>            node   0: [mem 0x000000008e300000-0x000000008ecfffff]
>>            node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
>>            node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>>            node   0: [mem 0x00000000de700000-0x00000000de9fffff]
>>            node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>>            node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>>            node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
>>
>>          ----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86a00, 86a00000
>>          ----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e300, 8e300000
>>          ----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
>>          ----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700, de700000
>>          ----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
>>          ----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
>>          ----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000
>>          === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
>>          :  pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
>>          8<--- cut here ---
>>          Unable to handle kernel paging request at virtual address fffffffe
>>          pgd = 5dd50df5
>>          [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
>>          Internal error: Oops: 37 [#1] SMP ARM
>>          Modules linked in: gmac(O)
>>          CPU: 2 PID: 635 Comm: test-oom Tainted: G           O      5.10.0+ #31
>>          Hardware name: Hisilicon A9
>>          PC is at move_freepages_block+0x150/0x278
>>          LR is at move_freepages_block+0x150/0x278
>>          pc : [<c02383a4>]    lr : [<c02383a4>]    psr: 200e0393
>>          sp : c4179cf8  ip : 00000000  fp : 00000001
>>          r10: c4179d58  r9 : 000de7ff  r8 : 00000000
>>          r7 : c0863280  r6 : 000de600  r5 : 000de600  r4 : ef3cc000
>>          r3 : ffffffff  r2 : 00000000  r1 : ef5d069c  r0 : fffffffe
>>          Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
>>          Control: 1ac5387d  Table: 83b0c04a  DAC: 55555555
>>          Process test-oom (pid: 635, stack limit = 0x25d667df)
>>
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-26 15:26               ` Kefeng Wang
@ 2021-04-27  6:23                 ` Mike Rapoport
  2021-04-27 11:08                   ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-27  6:23 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/26 13:20, Mike Rapoport wrote:
> > On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> > > On 2021/4/25 15:19, Mike Rapoport wrote:
> > > 
> > >      On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> > > 
> > >          I tested this patchset(plus arm32 change, like arm64 does)
> > >          based on lts 5.10,add some debug log, the useful info shows
> > >          below, if we enable HOLES_IN_ZONE, no panic, any idea,
> > >          thanks.
> > > 
> > >      Are there any changes on top of 5.10 except for pfn_valid() patch?
> > >      Do you see this panic on 5.10 without the changes?
> > > 
> > > Yes, there are some BSP support for arm board based on 5.10,

Is it possible to test 5.12?

> > > with or without your patch will get same panic, the panic pfn=de600
> > > in the range of [dcc00,de00] which is freed by free_memmap, start_pfn
> > > = dcc00,  dcc00000 end_pfn = de700, de700000
> > > 
> > > we see the PC is at PageLRU, same reason like arm64 panic log,
> > > 
> > >     "PageBuddy in move_freepages returns false
> > >      Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
> > >      compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
> > >      resturns 0xfffffffffffffffe - and accessing this address causes crash"
> > > 
> > >      Can you see stack backtrace beyond move_freepages_block?
> > > 
> > > I do some oom test, so the log is about memory allocate,
> > > 
> > > [<c02383c8>] (move_freepages_block) from [<c0238668>]
> > > (steal_suitable_fallback+0x174/0x1f4)
> > > 
> > > [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)
> >
> > Hmm, this is called with a page from free list, having a page from a freed
> > part of the memory map passed to steal_suitable_fallback() means that there
> > is an issue with creation of the free list.
> > 
> > Can you please add "memblock=debug" to the kernel command line and post the
> > log?
> 
> Here is the log,
> 
> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=1ac5387d
> 
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> OF: fdt: Machine model: HISI-CA9
> memblock_add: [0x80a00000-0x855fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x86a00000-0x87dfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x8bd00000-0x8c4fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x8e300000-0x8ecfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x90d00000-0xbfffffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xcc000000-0xdc9fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xe0800000-0xe0bfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xf5300000-0xf5bfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xf5c00000-0xf6ffffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xfe100000-0xfebfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xfec00000-0xffffffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xde700000-0xde9fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xf4b00000-0xf52fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xfda00000-0xfe0fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_reserve: [0x80a01000-0x80a02d2e] setup_arch+0x68/0x5c4
> Malformed early option 'vecpage_wrprotect'
> Memory policy: Data cache writealloc
> memblock_reserve: [0x80b00000-0x812e8057] arm_memblock_init+0x34/0x14c
> memblock_reserve: [0x83000000-0x84ffffff] arm_memblock_init+0x100/0x14c
> memblock_reserve: [0x80a04000-0x80a07fff] arm_memblock_init+0xa0/0x14c
> memblock_reserve: [0x80a00000-0x80a02fff] hisi_mem_reserve+0x14/0x30
> MEMBLOCK configuration:
>  memory size = 0x4c0fffff reserved size = 0x027ef058
>  memory.cnt  = 0xa
>  memory[0x0]    [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
>  memory[0x1]    [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
>  memory[0x2]    [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
>  memory[0x3]    [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
>  memory[0x4]    [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
>  memory[0x5]    [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
>  memory[0x6]    [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
>  memory[0x7]    [0xe0800000-0xe0bfffff], 0x00400000 bytes flags: 0x0
>  memory[0x8]    [0xf4b00000-0xf6ffffff], 0x02500000 bytes flags: 0x0
>  memory[0x9]    [0xfda00000-0xfffffffe], 0x025fffff bytes flags: 0x0
>  reserved.cnt  = 0x4
>  reserved[0x0]    [0x80a00000-0x80a02fff], 0x00003000 bytes flags: 0x0
>  reserved[0x1]    [0x80a04000-0x80a07fff], 0x00004000 bytes flags: 0x0
>  reserved[0x2]    [0x80b00000-0x812e8057], 0x007e8058 bytes flags: 0x0
>  reserved[0x3]    [0x83000000-0x84ffffff], 0x02000000 bytes flags: 0x0
...
> Zone ranges:
>   Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
>   HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x0000000080a00000-0x00000000855fffff]
>   node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
>   node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
>   node   0: [mem 0x000000008e300000-0x000000008ecfffff]
>   node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
>   node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>   node   0: [mem 0x00000000de700000-0x00000000de9fffff]
>   node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>   node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>   node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
> Zeroed struct page in unavailable ranges: 513 pages
> Initmem setup node 0 [mem 0x0000000080a00000-0x00000000ffffefff]
> On node 0 totalpages: 311551
>   Normal zone: 1230 pages used for memmap
>   Normal zone: 0 pages reserved
>   Normal zone: 157440 pages, LIFO batch:31
>   HighMem zone: 154111 pages, LIFO batch:31

AFAICT the range [de600000, de7ff000] should not be added to the free
lists.

Can you try with the below patch:

diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..7f3c33d53f87 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1994,6 +1994,8 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
 	unsigned long end_pfn = min_t(unsigned long,
 				      PFN_DOWN(end), max_low_pfn);
 
+	pr_info("%s: range: %pa - %pa, pfn: %lx - %lx\n", __func__, &start, &end, start_pfn, end_pfn);
+
 	if (start_pfn >= end_pfn)
 		return 0;
 
 
> > > [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
> > > [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
> > > [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
> > > [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
> > > [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
> > > [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
> > > 
> > >          Zone ranges:
> > >            Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
> > >            HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
> > >          Movable zone start for each node
> > >          Early memory node ranges
> > >            node   0: [mem 0x0000000080a00000-0x00000000855fffff]
> > >            node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
> > >            node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
> > >            node   0: [mem 0x000000008e300000-0x000000008ecfffff]
> > >            node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
> > >            node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
> > >            node   0: [mem 0x00000000de700000-0x00000000de9fffff]
> > >            node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
> > >            node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
> > >            node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
> > > 
> > >          ----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86a00, 86a00000
> > >          ----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e300, 8e300000
> > >          ----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
> > >          ----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700, de700000
> > >          ----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
> > >          ----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
> > >          ----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000
> > >          === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
> > >          :  pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
> > >          8<--- cut here ---
> > >          Unable to handle kernel paging request at virtual address fffffffe
> > >          pgd = 5dd50df5
> > >          [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
> > >          Internal error: Oops: 37 [#1] SMP ARM
> > >          Modules linked in: gmac(O)
> > >          CPU: 2 PID: 635 Comm: test-oom Tainted: G           O      5.10.0+ #31
> > >          Hardware name: Hisilicon A9
> > >          PC is at move_freepages_block+0x150/0x278
> > >          LR is at move_freepages_block+0x150/0x278
> > >          pc : [<c02383a4>]    lr : [<c02383a4>]    psr: 200e0393
> > >          sp : c4179cf8  ip : 00000000  fp : 00000001
> > >          r10: c4179d58  r9 : 000de7ff  r8 : 00000000
> > >          r7 : c0863280  r6 : 000de600  r5 : 000de600  r4 : ef3cc000
> > >          r3 : ffffffff  r2 : 00000000  r1 : ef5d069c  r0 : fffffffe
> > >          Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
> > >          Control: 1ac5387d  Table: 83b0c04a  DAC: 55555555
> > >          Process test-oom (pid: 635, stack limit = 0x25d667df)
> > > 
> > > 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-27  6:23                 ` Mike Rapoport
@ 2021-04-27 11:08                   ` Kefeng Wang
  2021-04-28  5:59                     ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-04-27 11:08 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm


On 2021/4/27 14:23, Mike Rapoport wrote:
> On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
>> On 2021/4/26 13:20, Mike Rapoport wrote:
>>> On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
>>>> On 2021/4/25 15:19, Mike Rapoport wrote:
>>>>
>>>>       On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
>>>>
>>>>           I tested this patchset(plus arm32 change, like arm64 does)
>>>>           based on lts 5.10,add some debug log, the useful info shows
>>>>           below, if we enable HOLES_IN_ZONE, no panic, any idea,
>>>>           thanks.
>>>>
>>>>       Are there any changes on top of 5.10 except for pfn_valid() patch?
>>>>       Do you see this panic on 5.10 without the changes?
>>>>
>>>> Yes, there are some BSP support for arm board based on 5.10,
> Is it possible to test 5.12?
>
>>>> with or without your patch will get same panic, the panic pfn=de600
>>>> in the range of [dcc00,de00] which is freed by free_memmap, start_pfn
>>>> = dcc00,  dcc00000 end_pfn = de700, de700000
>>>>
>>>> we see the PC is at PageLRU, same reason like arm64 panic log,
>>>>
>>>>      "PageBuddy in move_freepages returns false
>>>>       Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
>>>>       compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
>>>>       resturns 0xfffffffffffffffe - and accessing this address causes crash"
>>>>
>>>>       Can you see stack backtrace beyond move_freepages_block?
>>>>
>>>> I do some oom test, so the log is about memory allocate,
>>>>
>>>> [<c02383c8>] (move_freepages_block) from [<c0238668>]
>>>> (steal_suitable_fallback+0x174/0x1f4)
>>>>
>>>> [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)
>>> Hmm, this is called with a page from free list, having a page from a freed
>>> part of the memory map passed to steal_suitable_fallback() means that there
>>> is an issue with creation of the free list.
>>>
>>> Can you please add "memblock=debug" to the kernel command line and post the
>>> log?
>> Here is the log,
>>
>> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=1ac5387d
>>
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> OF: fdt: Machine model: HISI-CA9
>> memblock_add: [0x80a00000-0x855fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x86a00000-0x87dfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x8bd00000-0x8c4fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x8e300000-0x8ecfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x90d00000-0xbfffffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xcc000000-0xdc9fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xe0800000-0xe0bfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xf5300000-0xf5bfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xf5c00000-0xf6ffffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xfe100000-0xfebfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xfec00000-0xffffffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xde700000-0xde9fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xf4b00000-0xf52fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xfda00000-0xfe0fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_reserve: [0x80a01000-0x80a02d2e] setup_arch+0x68/0x5c4
>> Malformed early option 'vecpage_wrprotect'
>> Memory policy: Data cache writealloc
>> memblock_reserve: [0x80b00000-0x812e8057] arm_memblock_init+0x34/0x14c
>> memblock_reserve: [0x83000000-0x84ffffff] arm_memblock_init+0x100/0x14c
>> memblock_reserve: [0x80a04000-0x80a07fff] arm_memblock_init+0xa0/0x14c
>> memblock_reserve: [0x80a00000-0x80a02fff] hisi_mem_reserve+0x14/0x30
>> MEMBLOCK configuration:
>>   memory size = 0x4c0fffff reserved size = 0x027ef058
>>   memory.cnt  = 0xa
>>   memory[0x0]    [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
>>   memory[0x1]    [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
>>   memory[0x2]    [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
>>   memory[0x3]    [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
>>   memory[0x4]    [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
>>   memory[0x5]    [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
>>   memory[0x6]    [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
>>   memory[0x7]    [0xe0800000-0xe0bfffff], 0x00400000 bytes flags: 0x0
>>   memory[0x8]    [0xf4b00000-0xf6ffffff], 0x02500000 bytes flags: 0x0
>>   memory[0x9]    [0xfda00000-0xfffffffe], 0x025fffff bytes flags: 0x0
>>   reserved.cnt  = 0x4
>>   reserved[0x0]    [0x80a00000-0x80a02fff], 0x00003000 bytes flags: 0x0
>>   reserved[0x1]    [0x80a04000-0x80a07fff], 0x00004000 bytes flags: 0x0
>>   reserved[0x2]    [0x80b00000-0x812e8057], 0x007e8058 bytes flags: 0x0
>>   reserved[0x3]    [0x83000000-0x84ffffff], 0x02000000 bytes flags: 0x0
> ...
>> Zone ranges:
>>    Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
>>    HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
>> Movable zone start for each node
>> Early memory node ranges
>>    node   0: [mem 0x0000000080a00000-0x00000000855fffff]
>>    node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
>>    node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
>>    node   0: [mem 0x000000008e300000-0x000000008ecfffff]
>>    node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
>>    node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>>    node   0: [mem 0x00000000de700000-0x00000000de9fffff]
>>    node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>>    node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>>    node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
>> Zeroed struct page in unavailable ranges: 513 pages
>> Initmem setup node 0 [mem 0x0000000080a00000-0x00000000ffffefff]
>> On node 0 totalpages: 311551
>>    Normal zone: 1230 pages used for memmap
>>    Normal zone: 0 pages reserved
>>    Normal zone: 157440 pages, LIFO batch:31
>>    HighMem zone: 154111 pages, LIFO batch:31
> AFAICT the range [de600000, de7ff000] should not be added to the free
> lists.
>
> Can you try with the below patch:
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..7f3c33d53f87 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1994,6 +1994,8 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>   	unsigned long end_pfn = min_t(unsigned long,
>   				      PFN_DOWN(end), max_low_pfn);
>   
> +	pr_info("%s: range: %pa - %pa, pfn: %lx - %lx\n", __func__, &start, &end, start_pfn, end_pfn);
> +
>   	if (start_pfn >= end_pfn)
>   		return 0;
>   
__free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
__free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
__free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
__free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
__free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
__free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
__free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
__free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
__free_memory_core, range: 0xaf430000 - 0xaf454000, pfn: af430 - af454
__free_memory_core, range: 0xaf510000 - 0xaf546000, pfn: af510 - af546
__free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
__free_memory_core, range: 0xafd98000 - 0xafdce000, pfn: afd98 - afdce
__free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
__free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
__free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
__free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
__free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
__free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
__free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
__free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
__free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
__free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
__free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
__free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
__free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
__free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
__free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
__free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
__free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
__free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
__free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
__free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
__free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200

>   
>>>> [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
>>>> [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
>>>> [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
>>>> [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
>>>> [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
>>>> [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
>>>>
>>>>           Zone ranges:
>>>>             Normal   [mem 0x0000000080a00000-0x00000000b01fffff]
>>>>             HighMem  [mem 0x00000000b0200000-0x00000000ffffefff]
>>>>           Movable zone start for each node
>>>>           Early memory node ranges
>>>>             node   0: [mem 0x0000000080a00000-0x00000000855fffff]
>>>>             node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
>>>>             node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
>>>>             node   0: [mem 0x000000008e300000-0x000000008ecfffff]
>>>>             node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
>>>>             node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>>>>             node   0: [mem 0x00000000de700000-0x00000000de9fffff]
>>>>             node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>>>>             node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>>>>             node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
>>>>
>>>>           ----> free_memmap, start_pfn = 85800,  85800000 end_pfn = 86a00, 86a00000
>>>>           ----> free_memmap, start_pfn = 8c800,  8c800000 end_pfn = 8e300, 8e300000
>>>>           ----> free_memmap, start_pfn = 8f000,  8f000000 end_pfn = 90000, 90000000
>>>>           ----> free_memmap, start_pfn = dcc00,  dcc00000 end_pfn = de700, de700000
>>>>           ----> free_memmap, start_pfn = dec00,  dec00000 end_pfn = e0000, e0000000
>>>>           ----> free_memmap, start_pfn = e0c00,  e0c00000 end_pfn = e4000, e4000000
>>>>           ----> free_memmap, start_pfn = f7000,  f7000000 end_pfn = f8000, f8000000
>>>>           === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
>>>>           :  pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
>>>>           8<--- cut here ---
>>>>           Unable to handle kernel paging request at virtual address fffffffe
>>>>           pgd = 5dd50df5
>>>>           [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
>>>>           Internal error: Oops: 37 [#1] SMP ARM
>>>>           Modules linked in: gmac(O)
>>>>           CPU: 2 PID: 635 Comm: test-oom Tainted: G           O      5.10.0+ #31
>>>>           Hardware name: Hisilicon A9
>>>>           PC is at move_freepages_block+0x150/0x278
>>>>           LR is at move_freepages_block+0x150/0x278
>>>>           pc : [<c02383a4>]    lr : [<c02383a4>]    psr: 200e0393
>>>>           sp : c4179cf8  ip : 00000000  fp : 00000001
>>>>           r10: c4179d58  r9 : 000de7ff  r8 : 00000000
>>>>           r7 : c0863280  r6 : 000de600  r5 : 000de600  r4 : ef3cc000
>>>>           r3 : ffffffff  r2 : 00000000  r1 : ef5d069c  r0 : fffffffe
>>>>           Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
>>>>           Control: 1ac5387d  Table: 83b0c04a  DAC: 55555555
>>>>           Process test-oom (pid: 635, stack limit = 0x25d667df)
>>>>
>>>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-27 11:08                   ` Kefeng Wang
@ 2021-04-28  5:59                     ` Mike Rapoport
  2021-04-29  0:48                       ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-28  5:59 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Tue, Apr 27, 2021 at 07:08:59PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/27 14:23, Mike Rapoport wrote:
> > On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
> > > On 2021/4/26 13:20, Mike Rapoport wrote:
> > > > On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> > > > > On 2021/4/25 15:19, Mike Rapoport wrote:
> > > > > 
> > > > >       On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> > > > > 
> > > > >           I tested this patchset(plus arm32 change, like arm64 does)
> > > > >           based on lts 5.10,add some debug log, the useful info shows
> > > > >           below, if we enable HOLES_IN_ZONE, no panic, any idea,
> > > > >           thanks.
> > > > > 
> > > > >       Are there any changes on top of 5.10 except for pfn_valid() patch?
> > > > >       Do you see this panic on 5.10 without the changes?
> > > > > 
> > > > > Yes, there are some BSP support for arm board based on 5.10,
> > Is it possible to test 5.12?

Do you use SPARSMEM? If yes, what is your section size?
What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-28  5:59                     ` Mike Rapoport
@ 2021-04-29  0:48                       ` Kefeng Wang
  2021-04-29  6:57                         ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-04-29  0:48 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm


On 2021/4/28 13:59, Mike Rapoport wrote:
> On Tue, Apr 27, 2021 at 07:08:59PM +0800, Kefeng Wang wrote:
>> On 2021/4/27 14:23, Mike Rapoport wrote:
>>> On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
>>>> On 2021/4/26 13:20, Mike Rapoport wrote:
>>>>> On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
>>>>>> On 2021/4/25 15:19, Mike Rapoport wrote:
>>>>>>
>>>>>>        On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
>>>>>>
>>>>>>            I tested this patchset(plus arm32 change, like arm64 does)
>>>>>>            based on lts 5.10,add some debug log, the useful info shows
>>>>>>            below, if we enable HOLES_IN_ZONE, no panic, any idea,
>>>>>>            thanks.
>>>>>>
>>>>>>        Are there any changes on top of 5.10 except for pfn_valid() patch?
>>>>>>        Do you see this panic on 5.10 without the changes?
>>>>>>
>>>>>> Yes, there are some BSP support for arm board based on 5.10,
>>> Is it possible to test 5.12?
> Do you use SPARSMEM? If yes, what is your section size?
> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?

Yes,

CONFIG_SPARSEMEM=y

CONFIG_SPARSEMEM_STATIC=y

CONFIG_FORCE_MAX_ZONEORDER = 11

CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
#define SECTION_SIZE_BITS    26
#define MAX_PHYSADDR_BITS    32
#define MAX_PHYSMEM_BITS     32


>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-29  0:48                       ` Kefeng Wang
@ 2021-04-29  6:57                         ` Mike Rapoport
  2021-04-29 10:22                           ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-29  6:57 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Thu, Apr 29, 2021 at 08:48:26AM +0800, Kefeng Wang wrote:
> 
> On 2021/4/28 13:59, Mike Rapoport wrote:
> > On Tue, Apr 27, 2021 at 07:08:59PM +0800, Kefeng Wang wrote:
> > > On 2021/4/27 14:23, Mike Rapoport wrote:
> > > > On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
> > > > > On 2021/4/26 13:20, Mike Rapoport wrote:
> > > > > > On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> > > > > > > On 2021/4/25 15:19, Mike Rapoport wrote:
> > > > > > > 
> > > > > > >        On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> > > > > > > 
> > > > > > >            I tested this patchset(plus arm32 change, like arm64 does)
> > > > > > >            based on lts 5.10,add some debug log, the useful info shows
> > > > > > >            below, if we enable HOLES_IN_ZONE, no panic, any idea,
> > > > > > >            thanks.
> > > > > > > 
> > > > > > >        Are there any changes on top of 5.10 except for pfn_valid() patch?
> > > > > > >        Do you see this panic on 5.10 without the changes?
> > > > > > > 
> > > > > > > Yes, there are some BSP support for arm board based on 5.10,
> > > > Is it possible to test 5.12?
> > Do you use SPARSMEM? If yes, what is your section size?
> > What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
> 
> Yes,
> 
> CONFIG_SPARSEMEM=y
> 
> CONFIG_SPARSEMEM_STATIC=y
> 
> CONFIG_FORCE_MAX_ZONEORDER = 11
> 
> CONFIG_PAGE_OFFSET=0xC0000000
> CONFIG_HAVE_ARCH_PFN_VALID=y
> CONFIG_HIGHMEM=y
> #define SECTION_SIZE_BITS    26
> #define MAX_PHYSADDR_BITS    32
> #define MAX_PHYSMEM_BITS     32

It seems that with SPARSEMEM we don't align the freed parts on pageblock
boundaries.

Can you try the patch below:

diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..1926369b52ec 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
 		 * due to SPARSEMEM sections which aren't present.
 		 */
 		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
-#else
+#endif
 		/*
 		 * Align down here since the VM subsystem insists that the
 		 * memmap entries are valid from the bank start aligned to
 		 * MAX_ORDER_NR_PAGES.
 		 */
 		start = round_down(start, MAX_ORDER_NR_PAGES);
-#endif
 
 		/*
 		 * If we had a previous bank, and there is a space
 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-29  6:57                         ` Mike Rapoport
@ 2021-04-29 10:22                           ` Kefeng Wang
  2021-04-30  9:51                             ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-04-29 10:22 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm


On 2021/4/29 14:57, Mike Rapoport wrote:

>>> Do you use SPARSMEM? If yes, what is your section size?
>>> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
>> Yes,
>>
>> CONFIG_SPARSEMEM=y
>>
>> CONFIG_SPARSEMEM_STATIC=y
>>
>> CONFIG_FORCE_MAX_ZONEORDER = 11
>>
>> CONFIG_PAGE_OFFSET=0xC0000000
>> CONFIG_HAVE_ARCH_PFN_VALID=y
>> CONFIG_HIGHMEM=y
>> #define SECTION_SIZE_BITS    26
>> #define MAX_PHYSADDR_BITS    32
>> #define MAX_PHYSMEM_BITS     32


With the patch,  the addr is aligned, but the panic still occurred,

new free memory log is below,

memblock_free: [0xaf430000-0xaf44ffff] mem_init+0x158/0x23c

memblock_free: [0xaf510000-0xaf53ffff] mem_init+0x158/0x23c
memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x158/0x23c
memblock_free: [0xafd98000-0xafdc7fff] mem_init+0x158/0x23c
memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x158/0x23c
memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x158/0x23c
memblock_free: [0xafee0000-0xafefffff] mem_init+0x158/0x23c
__free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
__free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
__free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
__free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
__free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
__free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
__free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
__free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
__free_memory_core, range: 0xaf430000 - 0xaf450000, pfn: af430 - af450
__free_memory_core, range: 0xaf510000 - 0xaf540000, pfn: af510 - af540
__free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
__free_memory_core, range: 0xafd98000 - 0xafdc8000, pfn: afd98 - afdc8
__free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
__free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
__free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
__free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
__free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
__free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
__free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
__free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
__free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
__free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
__free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
__free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
__free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
__free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
__free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
__free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
__free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
__free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
__free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
__free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
__free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200
> It seems that with SPARSEMEM we don't align the freed parts on pageblock
> boundaries.
>
> Can you try the patch below:
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..1926369b52ec 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
>   		 * due to SPARSEMEM sections which aren't present.
>   		 */
>   		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
> -#else
> +#endif
>   		/*
>   		 * Align down here since the VM subsystem insists that the
>   		 * memmap entries are valid from the bank start aligned to
>   		 * MAX_ORDER_NR_PAGES.
>   		 */
>   		start = round_down(start, MAX_ORDER_NR_PAGES);
> -#endif
>   
>   		/*
>   		 * If we had a previous bank, and there is a space
>   
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-29 10:22                           ` Kefeng Wang
@ 2021-04-30  9:51                             ` Mike Rapoport
  2021-04-30 11:24                               ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-04-30  9:51 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/29 14:57, Mike Rapoport wrote:
> 
> > > > Do you use SPARSMEM? If yes, what is your section size?
> > > > What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
> > > Yes,
> > > 
> > > CONFIG_SPARSEMEM=y
> > > 
> > > CONFIG_SPARSEMEM_STATIC=y
> > > 
> > > CONFIG_FORCE_MAX_ZONEORDER = 11
> > > 
> > > CONFIG_PAGE_OFFSET=0xC0000000
> > > CONFIG_HAVE_ARCH_PFN_VALID=y
> > > CONFIG_HIGHMEM=y
> > > #define SECTION_SIZE_BITS    26
> > > #define MAX_PHYSADDR_BITS    32
> > > #define MAX_PHYSMEM_BITS     32
> 
> 
> With the patch,  the addr is aligned, but the panic still occurred,

Is this the same panic at move_freepages() for range [de600, de7ff]?

Do you enable CONFIG_ARM_LPAE?

> new free memory log is below,
> 
> memblock_free: [0xaf430000-0xaf44ffff] mem_init+0x158/0x23c
> 
> memblock_free: [0xaf510000-0xaf53ffff] mem_init+0x158/0x23c
> memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x158/0x23c
> memblock_free: [0xafd98000-0xafdc7fff] mem_init+0x158/0x23c
> memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x158/0x23c
> memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x158/0x23c
> memblock_free: [0xafee0000-0xafefffff] mem_init+0x158/0x23c
> __free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
> __free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
> __free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
> __free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
> __free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
> __free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
> __free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
> __free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
> __free_memory_core, range: 0xaf430000 - 0xaf450000, pfn: af430 - af450
> __free_memory_core, range: 0xaf510000 - 0xaf540000, pfn: af510 - af540
> __free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
> __free_memory_core, range: 0xafd98000 - 0xafdc8000, pfn: afd98 - afdc8
> __free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
> __free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
> __free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
> __free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
> __free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
> __free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
> __free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
> __free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
> __free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
> __free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
> __free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
> __free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
> __free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
> __free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
> __free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
> __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
> __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
> __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200

The range [de600, de7ff] 

> __free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
> __free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
> __free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200
> > It seems that with SPARSEMEM we don't align the freed parts on pageblock
> > boundaries.
> > 
> > Can you try the patch below:
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index afaefa8fc6ab..1926369b52ec 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
> >   		 * due to SPARSEMEM sections which aren't present.
> >   		 */
> >   		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
> > -#else
> > +#endif
> >   		/*
> >   		 * Align down here since the VM subsystem insists that the
> >   		 * memmap entries are valid from the bank start aligned to
> >   		 * MAX_ORDER_NR_PAGES.
> >   		 */
> >   		start = round_down(start, MAX_ORDER_NR_PAGES);
> > -#endif
> >   		/*
> >   		 * If we had a previous bank, and there is a space
> > 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-30  9:51                             ` Mike Rapoport
@ 2021-04-30 11:24                               ` Kefeng Wang
  2021-05-03  6:26                                 ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-04-30 11:24 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm



On 2021/4/30 17:51, Mike Rapoport wrote:
> On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
>>
>> On 2021/4/29 14:57, Mike Rapoport wrote:
>>
>>>>> Do you use SPARSMEM? If yes, what is your section size?
>>>>> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
>>>> Yes,
>>>>
>>>> CONFIG_SPARSEMEM=y
>>>>
>>>> CONFIG_SPARSEMEM_STATIC=y
>>>>
>>>> CONFIG_FORCE_MAX_ZONEORDER = 11
>>>>
>>>> CONFIG_PAGE_OFFSET=0xC0000000
>>>> CONFIG_HAVE_ARCH_PFN_VALID=y
>>>> CONFIG_HIGHMEM=y
>>>> #define SECTION_SIZE_BITS    26
>>>> #define MAX_PHYSADDR_BITS    32
>>>> #define MAX_PHYSMEM_BITS     32
>>
>>
>> With the patch,  the addr is aligned, but the panic still occurred,
> 
> Is this the same panic at move_freepages() for range [de600, de7ff]?
> 
> Do you enable CONFIG_ARM_LPAE?

no, the CONFIG_ARM_LPAE is not set, and yes with same panic at 
move_freepages at

start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] :  pfn =de600, 
page =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000



> 
>> new free memory log is below,
>>
>> memblock_free: [0xaf430000-0xaf44ffff] mem_init+0x158/0x23c
>>
>> memblock_free: [0xaf510000-0xaf53ffff] mem_init+0x158/0x23c
>> memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x158/0x23c
>> memblock_free: [0xafd98000-0xafdc7fff] mem_init+0x158/0x23c
>> memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x158/0x23c
>> memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x158/0x23c
>> memblock_free: [0xafee0000-0xafefffff] mem_init+0x158/0x23c
>> __free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
>> __free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
>> __free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
>> __free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
>> __free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
>> __free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
>> __free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
>> __free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
>> __free_memory_core, range: 0xaf430000 - 0xaf450000, pfn: af430 - af450
>> __free_memory_core, range: 0xaf510000 - 0xaf540000, pfn: af510 - af540
>> __free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
>> __free_memory_core, range: 0xafd98000 - 0xafdc8000, pfn: afd98 - afdc8
>> __free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
>> __free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
>> __free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
>> __free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
>> __free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
>> __free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
>> __free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
>> __free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
>> __free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
>> __free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
>> __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
>> __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
>> __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
> 
> The range [de600, de7ff]
the __free_memory_core will check the start pfn and end pfn,

  if (start_pfn >= end_pfn)
          return 0;

  __free_pages_memory(start_pfn, end_pfn);
so the memory will not be freed to buddy, confused...
> 
>> __free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
>> __free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
>> __free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200
>>> It seems that with SPARSEMEM we don't align the freed parts on pageblock
>>> boundaries.
>>>
>>> Can you try the patch below:
>>>
>>> diff --git a/mm/memblock.c b/mm/memblock.c
>>> index afaefa8fc6ab..1926369b52ec 100644
>>> --- a/mm/memblock.c
>>> +++ b/mm/memblock.c
>>> @@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
>>>    		 * due to SPARSEMEM sections which aren't present.
>>>    		 */
>>>    		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
>>> -#else
>>> +#endif
>>>    		/*
>>>    		 * Align down here since the VM subsystem insists that the
>>>    		 * memmap entries are valid from the bank start aligned to
>>>    		 * MAX_ORDER_NR_PAGES.
>>>    		 */
>>>    		start = round_down(start, MAX_ORDER_NR_PAGES);
>>> -#endif
>>>    		/*
>>>    		 * If we had a previous bank, and there is a space
>>>
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-04-30 11:24                               ` Kefeng Wang
@ 2021-05-03  6:26                                 ` Mike Rapoport
  2021-05-03  8:07                                   ` David Hildenbrand
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-05-03  6:26 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, David Hildenbrand, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Fri, Apr 30, 2021 at 07:24:37PM +0800, Kefeng Wang wrote:
> 
> 
> On 2021/4/30 17:51, Mike Rapoport wrote:
> > On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
> > > 
> > > On 2021/4/29 14:57, Mike Rapoport wrote:
> > > 
> > > > > > Do you use SPARSMEM? If yes, what is your section size?
> > > > > > What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
> > > > > Yes,
> > > > > 
> > > > > CONFIG_SPARSEMEM=y
> > > > > 
> > > > > CONFIG_SPARSEMEM_STATIC=y
> > > > > 
> > > > > CONFIG_FORCE_MAX_ZONEORDER = 11
> > > > > 
> > > > > CONFIG_PAGE_OFFSET=0xC0000000
> > > > > CONFIG_HAVE_ARCH_PFN_VALID=y
> > > > > CONFIG_HIGHMEM=y
> > > > > #define SECTION_SIZE_BITS    26
> > > > > #define MAX_PHYSADDR_BITS    32
> > > > > #define MAX_PHYSMEM_BITS     32
> > > 
> > > 
> > > With the patch,  the addr is aligned, but the panic still occurred,
> > 
> > Is this the same panic at move_freepages() for range [de600, de7ff]?
> > 
> > Do you enable CONFIG_ARM_LPAE?
> 
> no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
> move_freepages at
> 
> start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] :  pfn =de600, page
> =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
> 
> > > __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
> > > __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
> > > __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200

Hmm, [de600, de7ff] is not added to the free lists which is correct. But
then it's unclear how the page for de600 gets to move_freepages()...

Can't say I have any bright ideas to try here...

> the __free_memory_core will check the start pfn and end pfn,
> 
>  if (start_pfn >= end_pfn)
>          return 0;
> 
>  __free_pages_memory(start_pfn, end_pfn);
> so the memory will not be freed to buddy, confused...

It's a check for range validity, all valid ranges are added.

> > > __free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
> > > __free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
> > > __free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200
> > > > It seems that with SPARSEMEM we don't align the freed parts on pageblock
> > > > boundaries.
> > > > 
> > > > Can you try the patch below:
> > > > 
> > > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > > index afaefa8fc6ab..1926369b52ec 100644
> > > > --- a/mm/memblock.c
> > > > +++ b/mm/memblock.c
> > > > @@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
> > > >    		 * due to SPARSEMEM sections which aren't present.
> > > >    		 */
> > > >    		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
> > > > -#else
> > > > +#endif
> > > >    		/*
> > > >    		 * Align down here since the VM subsystem insists that the
> > > >    		 * memmap entries are valid from the bank start aligned to
> > > >    		 * MAX_ORDER_NR_PAGES.
> > > >    		 */
> > > >    		start = round_down(start, MAX_ORDER_NR_PAGES);
> > > > -#endif
> > > >    		/*
> > > >    		 * If we had a previous bank, and there is a space
> > > > 
> > 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-05-03  6:26                                 ` Mike Rapoport
@ 2021-05-03  8:07                                   ` David Hildenbrand
  2021-05-03  8:44                                     ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: David Hildenbrand @ 2021-05-03  8:07 UTC (permalink / raw)
  To: Mike Rapoport, Kefeng Wang
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Will Deacon, kvmarm, linux-kernel, linux-mm

On 03.05.21 08:26, Mike Rapoport wrote:
> On Fri, Apr 30, 2021 at 07:24:37PM +0800, Kefeng Wang wrote:
>>
>>
>> On 2021/4/30 17:51, Mike Rapoport wrote:
>>> On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
>>>>
>>>> On 2021/4/29 14:57, Mike Rapoport wrote:
>>>>
>>>>>>> Do you use SPARSMEM? If yes, what is your section size?
>>>>>>> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
>>>>>> Yes,
>>>>>>
>>>>>> CONFIG_SPARSEMEM=y
>>>>>>
>>>>>> CONFIG_SPARSEMEM_STATIC=y
>>>>>>
>>>>>> CONFIG_FORCE_MAX_ZONEORDER = 11
>>>>>>
>>>>>> CONFIG_PAGE_OFFSET=0xC0000000
>>>>>> CONFIG_HAVE_ARCH_PFN_VALID=y
>>>>>> CONFIG_HIGHMEM=y
>>>>>> #define SECTION_SIZE_BITS    26
>>>>>> #define MAX_PHYSADDR_BITS    32
>>>>>> #define MAX_PHYSMEM_BITS     32
>>>>
>>>>
>>>> With the patch,  the addr is aligned, but the panic still occurred,
>>>
>>> Is this the same panic at move_freepages() for range [de600, de7ff]?
>>>
>>> Do you enable CONFIG_ARM_LPAE?
>>
>> no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
>> move_freepages at
>>
>> start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] :  pfn =de600, page
>> =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
>>
>>>> __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
>>>> __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
>>>> __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
> 
> Hmm, [de600, de7ff] is not added to the free lists which is correct. But
> then it's unclear how the page for de600 gets to move_freepages()...
> 
> Can't say I have any bright ideas to try here...

Are we missing some checks (e.g., PageReserved()) that 
pfn_valid_within() would have "caught" before?

-- 
Thanks,

David / dhildenb


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-05-03  8:07                                   ` David Hildenbrand
@ 2021-05-03  8:44                                     ` Mike Rapoport
  2021-05-06 12:47                                       ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-05-03  8:44 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Kefeng Wang, linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Will Deacon, kvmarm, linux-kernel, linux-mm

On Mon, May 03, 2021 at 10:07:01AM +0200, David Hildenbrand wrote:
> On 03.05.21 08:26, Mike Rapoport wrote:
> > On Fri, Apr 30, 2021 at 07:24:37PM +0800, Kefeng Wang wrote:
> > > 
> > > 
> > > On 2021/4/30 17:51, Mike Rapoport wrote:
> > > > On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
> > > > > 
> > > > > On 2021/4/29 14:57, Mike Rapoport wrote:
> > > > > 
> > > > > > > > Do you use SPARSMEM? If yes, what is your section size?
> > > > > > > > What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
> > > > > > > Yes,
> > > > > > > 
> > > > > > > CONFIG_SPARSEMEM=y
> > > > > > > 
> > > > > > > CONFIG_SPARSEMEM_STATIC=y
> > > > > > > 
> > > > > > > CONFIG_FORCE_MAX_ZONEORDER = 11
> > > > > > > 
> > > > > > > CONFIG_PAGE_OFFSET=0xC0000000
> > > > > > > CONFIG_HAVE_ARCH_PFN_VALID=y
> > > > > > > CONFIG_HIGHMEM=y
> > > > > > > #define SECTION_SIZE_BITS    26
> > > > > > > #define MAX_PHYSADDR_BITS    32
> > > > > > > #define MAX_PHYSMEM_BITS     32
> > > > > 
> > > > > 
> > > > > With the patch,  the addr is aligned, but the panic still occurred,
> > > > 
> > > > Is this the same panic at move_freepages() for range [de600, de7ff]?
> > > > 
> > > > Do you enable CONFIG_ARM_LPAE?
> > > 
> > > no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
> > > move_freepages at
> > > 
> > > start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] :  pfn =de600, page
> > > =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
> > > 
> > > > > __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
> > > > > __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
> > > > > __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
> > 
> > Hmm, [de600, de7ff] is not added to the free lists which is correct. But
> > then it's unclear how the page for de600 gets to move_freepages()...
> > 
> > Can't say I have any bright ideas to try here...
> 
> Are we missing some checks (e.g., PageReserved()) that pfn_valid_within()
> would have "caught" before?

Unless I'm missing something the crash happens in __rmqueue_fallback():

do_steal:
	page = get_page_from_free_area(area, fallback_mt);

	steal_suitable_fallback(zone, page, alloc_flags, start_migratetype,
								can_steal);
		-> move_freepages() 
			-> BUG()

So a page from free area should be sane as the freed range was never added
it to the free lists.

And honestly, with the memory layout reported elsewhere in the stack I'd
say that the bootloader/fdt beg for fixes...

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-05-03  8:44                                     ` Mike Rapoport
@ 2021-05-06 12:47                                       ` Kefeng Wang
  2021-05-07  7:17                                         ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-05-06 12:47 UTC (permalink / raw)
  To: Mike Rapoport, David Hildenbrand
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Will Deacon, kvmarm, linux-kernel, linux-mm



On 2021/5/3 16:44, Mike Rapoport wrote:
> On Mon, May 03, 2021 at 10:07:01AM +0200, David Hildenbrand wrote:
>> On 03.05.21 08:26, Mike Rapoport wrote:
>>> On Fri, Apr 30, 2021 at 07:24:37PM +0800, Kefeng Wang wrote:
>>>>
>>>>
>>>> On 2021/4/30 17:51, Mike Rapoport wrote:
>>>>> On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
>>>>>>
>>>>>> On 2021/4/29 14:57, Mike Rapoport wrote:
>>>>>>
>>>>>>>>> Do you use SPARSMEM? If yes, what is your section size?
>>>>>>>>> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
>>>>>>>> Yes,
>>>>>>>>
>>>>>>>> CONFIG_SPARSEMEM=y
>>>>>>>>
>>>>>>>> CONFIG_SPARSEMEM_STATIC=y
>>>>>>>>
>>>>>>>> CONFIG_FORCE_MAX_ZONEORDER = 11
>>>>>>>>
>>>>>>>> CONFIG_PAGE_OFFSET=0xC0000000
>>>>>>>> CONFIG_HAVE_ARCH_PFN_VALID=y
>>>>>>>> CONFIG_HIGHMEM=y
>>>>>>>> #define SECTION_SIZE_BITS    26
>>>>>>>> #define MAX_PHYSADDR_BITS    32
>>>>>>>> #define MAX_PHYSMEM_BITS     32
>>>>>>
>>>>>>
>>>>>> With the patch,  the addr is aligned, but the panic still occurred,
>>>>>
>>>>> Is this the same panic at move_freepages() for range [de600, de7ff]?
>>>>>
>>>>> Do you enable CONFIG_ARM_LPAE?
>>>>
>>>> no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
>>>> move_freepages at
>>>>
>>>> start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] :  pfn =de600, page
>>>> =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
>>>>
>>>>>> __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
>>>>>> __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
>>>>>> __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
>>>
>>> Hmm, [de600, de7ff] is not added to the free lists which is correct. But
>>> then it's unclear how the page for de600 gets to move_freepages()...
>>>
>>> Can't say I have any bright ideas to try here...
>>
>> Are we missing some checks (e.g., PageReserved()) that pfn_valid_within()
>> would have "caught" before?
> 
> Unless I'm missing something the crash happens in __rmqueue_fallback():
> 
> do_steal:
> 	page = get_page_from_free_area(area, fallback_mt);
> 
> 	steal_suitable_fallback(zone, page, alloc_flags, start_migratetype,
> 								can_steal);
> 		-> move_freepages()
> 			-> BUG()
> 
> So a page from free area should be sane as the freed range was never added
> it to the free lists.

Sorry for the late response due to the vacation.

The pfn in range [de600, de7ff] won't be added into the free lists via 
__free_memory_core(), but the pfn could be added into freelists via 
free_highmem_page()

I add some debug[1] in add_to_free_list(), we could see the calltrace

free_highpages, range_pfn [b0200, c0000], range_addr [b0200000, c0000000]
free_highpages, range_pfn [cc000, dca00], range_addr [cc000000, dca00000]
free_highpages, range_pfn [de700, dea00], range_addr [de700000, dea00000]
add_to_free_list, ===> pfn = de700
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:900 add_to_free_list+0x8c/0xec
pfn = de700
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #48
Hardware name: Hisilicon A9
[<c010a600>] (show_stack) from [<c04b21c4>] (dump_stack+0x9c/0xc0)
[<c04b21c4>] (dump_stack) from [<c011c708>] (__warn+0xc0/0xec)
[<c011c708>] (__warn) from [<c011c7a8>] (warn_slowpath_fmt+0x74/0xa4)
[<c011c7a8>] (warn_slowpath_fmt) from [<c023721c>] 
(add_to_free_list+0x8c/0xec)
[<c023721c>] (add_to_free_list) from [<c0237e00>] 
(free_pcppages_bulk+0x200/0x278)
[<c0237e00>] (free_pcppages_bulk) from [<c0238d14>] 
(free_unref_page+0x58/0x68)
[<c0238d14>] (free_unref_page) from [<c023bb54>] 
(free_highmem_page+0xc/0x50)
[<c023bb54>] (free_highmem_page) from [<c070620c>] (mem_init+0x21c/0x254)
[<c070620c>] (mem_init) from [<c0700b38>] (start_kernel+0x258/0x5c0)
[<c0700b38>] (start_kernel) from [<00000000>] (0x0)

so any idea?

[1] debug
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 1ba9f9f9dbd8..ee3619c04f93 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -286,7 +286,7 @@ static void __init free_highpages(void)
                 /* Truncate partial highmem entries */
                 if (start < max_low)
                         start = max_low;
-
+               pr_info("%s, range_pfn [%lx, %lx], range_addr [%x, 
%x]\n", __func__, start, end, range_start, range_end);
                 for (; start < end; start++)
                         free_highmem_page(pfn_to_page(start));

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 592479f43c74..920f041f0c6f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -892,7 +892,14 @@ compaction_capture(struct capture_control *capc, 
struct page *page,
  static inline void add_to_free_list(struct page *page, struct zone *zone,
                                     unsigned int order, int migratetype)
  {
+       unsigned long pfn;
         struct free_area *area = &zone->free_area[order];
+       pfn = page_to_pfn(page);
+       if (pfn >= 0xde600 && pfn < 0xde7ff) {
+               pr_info("%s, ===> pfn = %lx", __func__, pfn);
+               WARN_ONCE(pfn == 0xde700, "pfn = %lx", pfn);
+       }



> 
> And honestly, with the memory layout reported elsewhere in the stack I'd
> say that the bootloader/fdt beg for fixes...
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-05-06 12:47                                       ` Kefeng Wang
@ 2021-05-07  7:17                                         ` Kefeng Wang
  2021-05-07 10:30                                           ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-05-07  7:17 UTC (permalink / raw)
  To: Mike Rapoport, David Hildenbrand
  Cc: linux-arm-kernel, Andrew Morton, Anshuman Khandual,
	Ard Biesheuvel, Catalin Marinas, Marc Zyngier, Mark Rutland,
	Mike Rapoport, Will Deacon, kvmarm, linux-kernel, linux-mm



On 2021/5/6 20:47, Kefeng Wang wrote:
> 
> 
>>>>> no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
>>>>> move_freepages at
>>>>>
>>>>> start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] :  pfn 
>>>>> =de600, page
>>>>> =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
>>>>>
>>>>>>> __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - 
>>>>>>> b0200
>>>>>>> __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - 
>>>>>>> b0200
>>>>>>> __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - 
>>>>>>> b0200
>>>>
>>>> Hmm, [de600, de7ff] is not added to the free lists which is correct. 
>>>> But
>>>> then it's unclear how the page for de600 gets to move_freepages()...
>>>>
>>>> Can't say I have any bright ideas to try here...
>>>
>>> Are we missing some checks (e.g., PageReserved()) that 
>>> pfn_valid_within()
>>> would have "caught" before?
>>
>> Unless I'm missing something the crash happens in __rmqueue_fallback():
>>
>> do_steal:
>>     page = get_page_from_free_area(area, fallback_mt);
>>
>>     steal_suitable_fallback(zone, page, alloc_flags, start_migratetype,
>>                                 can_steal);
>>         -> move_freepages()
>>             -> BUG()
>>
>> So a page from free area should be sane as the freed range was never 
>> added
>> it to the free lists.
> 
> Sorry for the late response due to the vacation.
> 
> The pfn in range [de600, de7ff] won't be added into the free lists via 
> __free_memory_core(), but the pfn could be added into freelists via 
> free_highmem_page()
> 
> I add some debug[1] in add_to_free_list(), we could see the calltrace
> 
> free_highpages, range_pfn [b0200, c0000], range_addr [b0200000, c0000000]
> free_highpages, range_pfn [cc000, dca00], range_addr [cc000000, dca00000]
> free_highpages, range_pfn [de700, dea00], range_addr [de700000, dea00000]
> add_to_free_list, ===> pfn = de700
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:900 add_to_free_list+0x8c/0xec
> pfn = de700
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #48
> Hardware name: Hisilicon A9
> [<c010a600>] (show_stack) from [<c04b21c4>] (dump_stack+0x9c/0xc0)
> [<c04b21c4>] (dump_stack) from [<c011c708>] (__warn+0xc0/0xec)
> [<c011c708>] (__warn) from [<c011c7a8>] (warn_slowpath_fmt+0x74/0xa4)
> [<c011c7a8>] (warn_slowpath_fmt) from [<c023721c>] 
> (add_to_free_list+0x8c/0xec)
> [<c023721c>] (add_to_free_list) from [<c0237e00>] 
> (free_pcppages_bulk+0x200/0x278)
> [<c0237e00>] (free_pcppages_bulk) from [<c0238d14>] 
> (free_unref_page+0x58/0x68)
> [<c0238d14>] (free_unref_page) from [<c023bb54>] 
> (free_highmem_page+0xc/0x50)
> [<c023bb54>] (free_highmem_page) from [<c070620c>] (mem_init+0x21c/0x254)
> [<c070620c>] (mem_init) from [<c0700b38>] (start_kernel+0x258/0x5c0)
> [<c0700b38>] (start_kernel) from [<00000000>] (0x0)
> 
> so any idea?

If pfn = 0xde700, due to the pageblock_nr_pages = 0x200, then the 
start_pfn,end_pfn passed to move_freepages() will be [de600, de7ff],
but the range of [de600,de700] without ‘struct page' will lead to
this panic when pfn_valid_within not enabled if no HOLES_IN_ZONE,
and the same issue will occurred in isolate_freepages_block(), maybe
there are some scene, so I select HOLES_IN_ZONE in ARCH_HISI(ARM) to 
solve this issue in our 5.10, should we select HOLES_IN_ZONE in all ARM 
or only in ARCH_HISI, any better solution?  Thanks.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-05-07  7:17                                         ` Kefeng Wang
@ 2021-05-07 10:30                                           ` Mike Rapoport
  2021-05-07 12:34                                             ` Kefeng Wang
  0 siblings, 1 reply; 39+ messages in thread
From: Mike Rapoport @ 2021-05-07 10:30 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: David Hildenbrand, linux-arm-kernel, Andrew Morton,
	Anshuman Khandual, Ard Biesheuvel, Catalin Marinas, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Fri, May 07, 2021 at 03:17:08PM +0800, Kefeng Wang wrote:
> 
> On 2021/5/6 20:47, Kefeng Wang wrote:
> > 
> > 
> > > > > > no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
> > > > > > move_freepages at
> > > > > > 
> > > > > > start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000]
> > > > > > :  pfn =de600, page
> > > > > > =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
> > > > > > 
> > > > > > > > __free_memory_core, range: 0xb0200000 -
> > > > > > > > 0xc0000000, pfn: b0200 - b0200
> > > > > > > > __free_memory_core, range: 0xcc000000 -
> > > > > > > > 0xdca00000, pfn: cc000 - b0200
> > > > > > > > __free_memory_core, range: 0xde700000 -
> > > > > > > > 0xdea00000, pfn: de700 - b0200
> > > > > 
> > > > > Hmm, [de600, de7ff] is not added to the free lists which is
> > > > > correct. But
> > > > > then it's unclear how the page for de600 gets to move_freepages()...
> > > > > 
> > > > > Can't say I have any bright ideas to try here...
> > > > 
> > > > Are we missing some checks (e.g., PageReserved()) that
> > > > pfn_valid_within()
> > > > would have "caught" before?
> > > 
> > > Unless I'm missing something the crash happens in __rmqueue_fallback():
> > > 
> > > do_steal:
> > >     page = get_page_from_free_area(area, fallback_mt);
> > > 
> > >     steal_suitable_fallback(zone, page, alloc_flags, start_migratetype,
> > >                                 can_steal);
> > >         -> move_freepages()
> > >             -> BUG()
> > > 
> > > So a page from free area should be sane as the freed range was never
> > > added
> > > it to the free lists.
> > 
> > Sorry for the late response due to the vacation.
> > 
> > The pfn in range [de600, de7ff] won't be added into the free lists via
> > __free_memory_core(), but the pfn could be added into freelists via
> > free_highmem_page()
> > 
> > I add some debug[1] in add_to_free_list(), we could see the calltrace
> > 
> > free_highpages, range_pfn [b0200, c0000], range_addr [b0200000, c0000000]
> > free_highpages, range_pfn [cc000, dca00], range_addr [cc000000, dca00000]
> > free_highpages, range_pfn [de700, dea00], range_addr [de700000, dea00000]
> > add_to_free_list, ===> pfn = de700
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:900 add_to_free_list+0x8c/0xec
> > pfn = de700
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #48
> > Hardware name: Hisilicon A9
> > [<c010a600>] (show_stack) from [<c04b21c4>] (dump_stack+0x9c/0xc0)
> > [<c04b21c4>] (dump_stack) from [<c011c708>] (__warn+0xc0/0xec)
> > [<c011c708>] (__warn) from [<c011c7a8>] (warn_slowpath_fmt+0x74/0xa4)
> > [<c011c7a8>] (warn_slowpath_fmt) from [<c023721c>]
> > (add_to_free_list+0x8c/0xec)
> > [<c023721c>] (add_to_free_list) from [<c0237e00>]
> > (free_pcppages_bulk+0x200/0x278)
> > [<c0237e00>] (free_pcppages_bulk) from [<c0238d14>]
> > (free_unref_page+0x58/0x68)
> > [<c0238d14>] (free_unref_page) from [<c023bb54>]
> > (free_highmem_page+0xc/0x50)
> > [<c023bb54>] (free_highmem_page) from [<c070620c>] (mem_init+0x21c/0x254)
> > [<c070620c>] (mem_init) from [<c0700b38>] (start_kernel+0x258/0x5c0)
> > [<c0700b38>] (start_kernel) from [<00000000>] (0x0)
> > 
> > so any idea?
> 
> If pfn = 0xde700, due to the pageblock_nr_pages = 0x200, then the
> start_pfn,end_pfn passed to move_freepages() will be [de600, de7ff],
> but the range of [de600,de700] without ‘struct page' will lead to
> this panic when pfn_valid_within not enabled if no HOLES_IN_ZONE,
> and the same issue will occurred in isolate_freepages_block(), maybe

I think your analysis is correct except one minor detail. With the #ifdef
fix I've proposed earlieri [1] the memmap for [0xde600, 0xde700] should not
be freed so there should be a struct page. Did you check what parts of the
memmap are actually freed with this patch applied?
Would you get a panic if you add

	dump_page(pfn_to_page(0xde600), "");

say, in the end of memblock_free_all()?

> there are some scene, so I select HOLES_IN_ZONE in ARCH_HISI(ARM) to solve
> this issue in our 5.10, should we select HOLES_IN_ZONE in all ARM or only in
> ARCH_HISI, any better solution?  Thanks.

I don't think that HOLES_IN_ZONE is the right solution. I believe that we
must keep the memory map aligned on pageblock boundaries. That's surely not the
case for SPARSEMEM as of now, and if my fix is not enough we need to find
where it went wrong.

Besides, I'd say that if it is possible to update your firmware to make the
memory layout reported to the kernel less, hmm, esoteric, you would hit
less corner cases.

[1] https://lore.kernel.org/lkml/YIpY8TXCSc7Lfa2Z@kernel.org

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-05-07 10:30                                           ` Mike Rapoport
@ 2021-05-07 12:34                                             ` Kefeng Wang
  2021-05-09  5:59                                               ` Mike Rapoport
  0 siblings, 1 reply; 39+ messages in thread
From: Kefeng Wang @ 2021-05-07 12:34 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: David Hildenbrand, linux-arm-kernel, Andrew Morton,
	Anshuman Khandual, Ard Biesheuvel, Catalin Marinas, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm



On 2021/5/7 18:30, Mike Rapoport wrote:
> On Fri, May 07, 2021 at 03:17:08PM +0800, Kefeng Wang wrote:
>>
>> On 2021/5/6 20:47, Kefeng Wang wrote:
>>>
>>>
>>>>>>> no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
>>>>>>> move_freepages at
>>>>>>>
>>>>>>> start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000]
>>>>>>> :  pfn =de600, page
>>>>>>> =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
>>>>>>>
>>>>>>>>> __free_memory_core, range: 0xb0200000 -
>>>>>>>>> 0xc0000000, pfn: b0200 - b0200
>>>>>>>>> __free_memory_core, range: 0xcc000000 -
>>>>>>>>> 0xdca00000, pfn: cc000 - b0200
>>>>>>>>> __free_memory_core, range: 0xde700000 -
>>>>>>>>> 0xdea00000, pfn: de700 - b0200
>>>>>>
>>>>>> Hmm, [de600, de7ff] is not added to the free lists which is
>>>>>> correct. But
>>>>>> then it's unclear how the page for de600 gets to move_freepages()...
>>>>>>
>>>>>> Can't say I have any bright ideas to try here...
>>>>>
>>>>> Are we missing some checks (e.g., PageReserved()) that
>>>>> pfn_valid_within()
>>>>> would have "caught" before?
>>>>
>>>> Unless I'm missing something the crash happens in __rmqueue_fallback():
>>>>
>>>> do_steal:
>>>>      page = get_page_from_free_area(area, fallback_mt);
>>>>
>>>>      steal_suitable_fallback(zone, page, alloc_flags, start_migratetype,
>>>>                                  can_steal);
>>>>          -> move_freepages()
>>>>              -> BUG()
>>>>
>>>> So a page from free area should be sane as the freed range was never
>>>> added
>>>> it to the free lists.
>>>
>>> Sorry for the late response due to the vacation.
>>>
>>> The pfn in range [de600, de7ff] won't be added into the free lists via
>>> __free_memory_core(), but the pfn could be added into freelists via
>>> free_highmem_page()
>>>
>>> I add some debug[1] in add_to_free_list(), we could see the calltrace
>>>
>>> free_highpages, range_pfn [b0200, c0000], range_addr [b0200000, c0000000]
>>> free_highpages, range_pfn [cc000, dca00], range_addr [cc000000, dca00000]
>>> free_highpages, range_pfn [de700, dea00], range_addr [de700000, dea00000]
>>> add_to_free_list, ===> pfn = de700
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:900 add_to_free_list+0x8c/0xec
>>> pfn = de700
>>> Modules linked in:
>>> CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #48
>>> Hardware name: Hisilicon A9
>>> [<c010a600>] (show_stack) from [<c04b21c4>] (dump_stack+0x9c/0xc0)
>>> [<c04b21c4>] (dump_stack) from [<c011c708>] (__warn+0xc0/0xec)
>>> [<c011c708>] (__warn) from [<c011c7a8>] (warn_slowpath_fmt+0x74/0xa4)
>>> [<c011c7a8>] (warn_slowpath_fmt) from [<c023721c>]
>>> (add_to_free_list+0x8c/0xec)
>>> [<c023721c>] (add_to_free_list) from [<c0237e00>]
>>> (free_pcppages_bulk+0x200/0x278)
>>> [<c0237e00>] (free_pcppages_bulk) from [<c0238d14>]
>>> (free_unref_page+0x58/0x68)
>>> [<c0238d14>] (free_unref_page) from [<c023bb54>]
>>> (free_highmem_page+0xc/0x50)
>>> [<c023bb54>] (free_highmem_page) from [<c070620c>] (mem_init+0x21c/0x254)
>>> [<c070620c>] (mem_init) from [<c0700b38>] (start_kernel+0x258/0x5c0)
>>> [<c0700b38>] (start_kernel) from [<00000000>] (0x0)
>>>
>>> so any idea?
>>
>> If pfn = 0xde700, due to the pageblock_nr_pages = 0x200, then the
>> start_pfn,end_pfn passed to move_freepages() will be [de600, de7ff],
>> but the range of [de600,de700] without ‘struct page' will lead to
>> this panic when pfn_valid_within not enabled if no HOLES_IN_ZONE,
>> and the same issue will occurred in isolate_freepages_block(), maybe
> 
> I think your analysis is correct except one minor detail. With the #ifdef
> fix I've proposed earlieri [1] the memmap for [0xde600, 0xde700] should not
> be freed so there should be a struct page. Did you check what parts of the
> memmap are actually freed with this patch applied?
> Would you get a panic if you add
> 
> 	dump_page(pfn_to_page(0xde600), "");
> 
> say, in the end of memblock_free_all()?

The memory is not continuous, see MEMBLOCK:
  memory size = 0x4c0fffff reserved size = 0x027ef058
  memory.cnt  = 0xa
  memory[0x0]    [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
  memory[0x1]    [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
  memory[0x2]    [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
  memory[0x3]    [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
  memory[0x4]    [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
  memory[0x5]    [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
  memory[0x6]    [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
...

The pfn_range [0xde600,0xde700] => addr_range [0xde600000,0xde700000]
is not available memory, and we won't create memmap , so with or without 
your patch, we can't see the range in free_memmap(), right?

> 
>> there are some scene, so I select HOLES_IN_ZONE in ARCH_HISI(ARM) to solve
>> this issue in our 5.10, should we select HOLES_IN_ZONE in all ARM or only in
>> ARCH_HISI, any better solution?  Thanks.
> 
> I don't think that HOLES_IN_ZONE is the right solution. I believe that we
> must keep the memory map aligned on pageblock boundaries. That's surely not the
> case for SPARSEMEM as of now, and if my fix is not enough we need to find
> where it went wrong.
> 
> Besides, I'd say that if it is possible to update your firmware to make the
> memory layout reported to the kernel less, hmm, esoteric, you would hit
> less corner cases.

Sorry, memory layout is customized and we can't change it, some memory 
is for special purposes by our production.
> 
> [1] https://lore.kernel.org/lkml/YIpY8TXCSc7Lfa2Z@kernel.org
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid())
  2021-05-07 12:34                                             ` Kefeng Wang
@ 2021-05-09  5:59                                               ` Mike Rapoport
  0 siblings, 0 replies; 39+ messages in thread
From: Mike Rapoport @ 2021-05-09  5:59 UTC (permalink / raw)
  To: Kefeng Wang
  Cc: David Hildenbrand, linux-arm-kernel, Andrew Morton,
	Anshuman Khandual, Ard Biesheuvel, Catalin Marinas, Marc Zyngier,
	Mark Rutland, Mike Rapoport, Will Deacon, kvmarm, linux-kernel,
	linux-mm

On Fri, May 07, 2021 at 08:34:52PM +0800, Kefeng Wang wrote:
> 
> 
> On 2021/5/7 18:30, Mike Rapoport wrote:
> > On Fri, May 07, 2021 at 03:17:08PM +0800, Kefeng Wang wrote:
> > > 
> > > On 2021/5/6 20:47, Kefeng Wang wrote:
> > > > 
> > > > > > > > no, the CONFIG_ARM_LPAE is not set, and yes with same panic at
> > > > > > > > move_freepages at
> > > > > > > > 
> > > > > > > > start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000]
> > > > > > > > :  pfn =de600, page
> > > > > > > > =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000
> > > > > > > > 
> > > > > > > > > > __free_memory_core, range: 0xb0200000 -
> > > > > > > > > > 0xc0000000, pfn: b0200 - b0200
> > > > > > > > > > __free_memory_core, range: 0xcc000000 -
> > > > > > > > > > 0xdca00000, pfn: cc000 - b0200
> > > > > > > > > > __free_memory_core, range: 0xde700000 -
> > > > > > > > > > 0xdea00000, pfn: de700 - b0200
> > > > > > > 
> > > > > > > Hmm, [de600, de7ff] is not added to the free lists which is
> > > > > > > correct. But
> > > > > > > then it's unclear how the page for de600 gets to move_freepages()...
> > > > > > > 
> > > > > > > Can't say I have any bright ideas to try here...
> > > > > > 
> > > > > > Are we missing some checks (e.g., PageReserved()) that
> > > > > > pfn_valid_within()
> > > > > > would have "caught" before?
> > > > > 
> > > > > Unless I'm missing something the crash happens in __rmqueue_fallback():
> > > > > 
> > > > > do_steal:
> > > > >      page = get_page_from_free_area(area, fallback_mt);
> > > > > 
> > > > >      steal_suitable_fallback(zone, page, alloc_flags, start_migratetype,
> > > > >                                  can_steal);
> > > > >          -> move_freepages()
> > > > >              -> BUG()
> > > > > 
> > > > > So a page from free area should be sane as the freed range was never
> > > > > added
> > > > > it to the free lists.
> > > > 
> > > > Sorry for the late response due to the vacation.
> > > > 
> > > > The pfn in range [de600, de7ff] won't be added into the free lists via
> > > > __free_memory_core(), but the pfn could be added into freelists via
> > > > free_highmem_page()
> > > > 
> > > > I add some debug[1] in add_to_free_list(), we could see the calltrace
> > > > 
> > > > free_highpages, range_pfn [b0200, c0000], range_addr [b0200000, c0000000]
> > > > free_highpages, range_pfn [cc000, dca00], range_addr [cc000000, dca00000]
> > > > free_highpages, range_pfn [de700, dea00], range_addr [de700000, dea00000]
> > > > add_to_free_list, ===> pfn = de700
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:900 add_to_free_list+0x8c/0xec
> > > > pfn = de700
> > > > Modules linked in:
> > > > CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #48
> > > > Hardware name: Hisilicon A9
> > > > [<c010a600>] (show_stack) from [<c04b21c4>] (dump_stack+0x9c/0xc0)
> > > > [<c04b21c4>] (dump_stack) from [<c011c708>] (__warn+0xc0/0xec)
> > > > [<c011c708>] (__warn) from [<c011c7a8>] (warn_slowpath_fmt+0x74/0xa4)
> > > > [<c011c7a8>] (warn_slowpath_fmt) from [<c023721c>]
> > > > (add_to_free_list+0x8c/0xec)
> > > > [<c023721c>] (add_to_free_list) from [<c0237e00>]
> > > > (free_pcppages_bulk+0x200/0x278)
> > > > [<c0237e00>] (free_pcppages_bulk) from [<c0238d14>]
> > > > (free_unref_page+0x58/0x68)
> > > > [<c0238d14>] (free_unref_page) from [<c023bb54>]
> > > > (free_highmem_page+0xc/0x50)
> > > > [<c023bb54>] (free_highmem_page) from [<c070620c>] (mem_init+0x21c/0x254)
> > > > [<c070620c>] (mem_init) from [<c0700b38>] (start_kernel+0x258/0x5c0)
> > > > [<c0700b38>] (start_kernel) from [<00000000>] (0x0)
> > > > 
> > > > so any idea?
> > > 
> > > If pfn = 0xde700, due to the pageblock_nr_pages = 0x200, then the
> > > start_pfn,end_pfn passed to move_freepages() will be [de600, de7ff],
> > > but the range of [de600,de700] without ‘struct page' will lead to
> > > this panic when pfn_valid_within not enabled if no HOLES_IN_ZONE,
> > > and the same issue will occurred in isolate_freepages_block(), maybe
> > 
> > I think your analysis is correct except one minor detail. With the #ifdef
> > fix I've proposed earlieri [1] the memmap for [0xde600, 0xde700] should not
> > be freed so there should be a struct page. Did you check what parts of the
> > memmap are actually freed with this patch applied?
> > Would you get a panic if you add
> > 
> > 	dump_page(pfn_to_page(0xde600), "");
> > 
> > say, in the end of memblock_free_all()?
> 
> The memory is not continuous, see MEMBLOCK:
>  memory size = 0x4c0fffff reserved size = 0x027ef058
>  memory.cnt  = 0xa
>  memory[0x0]    [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
>  memory[0x1]    [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
>  memory[0x2]    [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
>  memory[0x3]    [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
>  memory[0x4]    [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
>  memory[0x5]    [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
>  memory[0x6]    [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
> ...
> 
> The pfn_range [0xde600,0xde700] => addr_range [0xde600000,0xde700000]
> is not available memory, and we won't create memmap , so with or without
> your patch, we can't see the range in free_memmap(), right?
 

This is not available memory and we won't see the reange in free_memmap(),
but we still should create memmap for it and that's what my patch tried to
do.

There are a lot of places in core mm that operate on pageblocks and
free_unused_memmap() should make sure that any pageblock has a valid memory
map.

Currently, that's not the case when SPARSEMEM=y and my patch tried to fix
it.

Can you please send log with my patch applied and with the printing of
ranges that are freed in free_unused_memmap() you've used in previous
mails?
 
> > > there are some scene, so I select HOLES_IN_ZONE in ARCH_HISI(ARM) to solve
> > > this issue in our 5.10, should we select HOLES_IN_ZONE in all ARM or only in
> > > ARCH_HISI, any better solution?  Thanks.
> > 
> > I don't think that HOLES_IN_ZONE is the right solution. I believe that we
> > must keep the memory map aligned on pageblock boundaries. That's surely not the
> > case for SPARSEMEM as of now, and if my fix is not enough we need to find
> > where it went wrong.
> > 
> > Besides, I'd say that if it is possible to update your firmware to make the
> > memory layout reported to the kernel less, hmm, esoteric, you would hit
> > less corner cases.
> 
> Sorry, memory layout is customized and we can't change it, some memory is
> for special purposes by our production.
 
I understand that this memory cannot be used by Linux, but the firmware may
supply the kernel with actual physical memory layout and then mark all
the special purpose memory that kernel should not touch as reserved.

> > [1] https://lore.kernel.org/lkml/YIpY8TXCSc7Lfa2Z@kernel.org
> > 

-- 
Sincerely yours,
Mike.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, back to index

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-21  6:51 [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-21  6:51 ` [PATCH v2 1/4] include/linux/mmzone.h: add documentation for pfn_valid() Mike Rapoport
2021-04-21 10:49   ` Anshuman Khandual
2021-04-21  6:51 ` [PATCH v2 2/4] memblock: update initialization of reserved pages Mike Rapoport
2021-04-21  7:49   ` David Hildenbrand
2021-04-21 10:51   ` Anshuman Khandual
2021-04-21  6:51 ` [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map from pfn_valid() Mike Rapoport
2021-04-21 10:59   ` Anshuman Khandual
2021-04-21 12:19     ` Mike Rapoport
2021-04-21 13:13       ` Anshuman Khandual
2021-04-21  6:51 ` [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport
2021-04-21  7:49   ` David Hildenbrand
2021-04-21 11:06   ` Anshuman Khandual
2021-04-21 12:24     ` Mike Rapoport
2021-04-21 13:15       ` Anshuman Khandual
2021-04-22  7:00 ` [PATCH v2 0/4] " Kefeng Wang
2021-04-22  7:29   ` Mike Rapoport
2021-04-22 15:28     ` Kefeng Wang
2021-04-23  8:11       ` Kefeng Wang
2021-04-25  7:19         ` arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()) Mike Rapoport
     [not found]           ` <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
2021-04-26  5:20             ` Mike Rapoport
2021-04-26 15:26               ` Kefeng Wang
2021-04-27  6:23                 ` Mike Rapoport
2021-04-27 11:08                   ` Kefeng Wang
2021-04-28  5:59                     ` Mike Rapoport
2021-04-29  0:48                       ` Kefeng Wang
2021-04-29  6:57                         ` Mike Rapoport
2021-04-29 10:22                           ` Kefeng Wang
2021-04-30  9:51                             ` Mike Rapoport
2021-04-30 11:24                               ` Kefeng Wang
2021-05-03  6:26                                 ` Mike Rapoport
2021-05-03  8:07                                   ` David Hildenbrand
2021-05-03  8:44                                     ` Mike Rapoport
2021-05-06 12:47                                       ` Kefeng Wang
2021-05-07  7:17                                         ` Kefeng Wang
2021-05-07 10:30                                           ` Mike Rapoport
2021-05-07 12:34                                             ` Kefeng Wang
2021-05-09  5:59                                               ` Mike Rapoport
2021-04-25  6:59       ` [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git