[PATCH 1/2] powerpc/mm: Check memblock_add against MAX_PHYSMEM_BITS range

[PATCH 1/2] powerpc/mm: Check memblock_add against MAX_PHYSMEM_BITS range

[Aneesh Kumar K.V]

With SPARSEMEM config enabled, we make sure that we don't add sections beyond
MAX_PHYSMEM_BITS range. This results in not building vmemmap mapping for
range beyond max range. But our memblock layer looks the device tree and create
mapping for the full memory range. Prevent this by checking against
MAX_PHSYSMEM_BITS when doing memblock_add.

We don't do similar check for memeblock_reserve_range. If reserve range is beyond
MAX_PHYSMEM_BITS we expect that to be configured with 'nomap'. Any other
reserved range should come from existing memblock ranges which we already
filtered while adding.

This avoids crash as below when running on a system with system ram config above
MAX_PHSYSMEM_BITS

 Unable to handle kernel paging request for data at address 0xc00a001000000440
 Faulting instruction address: 0xc000000001034118
 cpu 0x0: Vector: 300 (Data Access) at [c00000000124fb30]
     pc: c000000001034118: __free_pages_bootmem+0xc0/0x1c0
     lr: c00000000103b258: free_all_bootmem+0x19c/0x22c
     sp: c00000000124fdb0
    msr: 9000000002001033
    dar: c00a001000000440
  dsisr: 40000000
   current = 0xc00000000120dd00
   paca    = 0xc000000001f60000^I irqmask: 0x03^I irq_happened: 0x01
     pid   = 0, comm = swapper
 [c00000000124fe20] c00000000103b258 free_all_bootmem+0x19c/0x22c
 [c00000000124fee0] c000000001010a68 mem_init+0x3c/0x5c
 [c00000000124ff00] c00000000100401c start_kernel+0x298/0x5e4
 [c00000000124ff90] c00000000000b57c start_here_common+0x1c/0x520

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
 arch/powerpc/kernel/prom.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 05e7fb47a7a4..8f32f14ba508 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -440,6 +440,29 @@ static int __init early_init_dt_scan_chosen_ppc(unsigned long node,
 	return 1;
 }
 
+/*
+ * Compare the range against max mem limit and update
+ * size if it cross the limit.
+ */
+
+#ifdef CONFIG_SPARSEMEM
+static bool validate_mem_limit(u64 base, u64 *size)
+{
+	u64 max_mem = 1UL << (MAX_PHYSMEM_BITS);
+
+	if (base >= max_mem)
+		return false;
+	if ((base + *size) > max_mem)
+		*size = max_mem - base;
+	return true;
+}
+#else
+static bool validate_mem_limit(u64 base, u64 *size)
+{
+	return true;
+}
+#endif
+
 #ifdef CONFIG_PPC_PSERIES
 /*
  * Interpret the ibm dynamic reconfiguration memory LMBs.
@@ -494,7 +517,8 @@ static void __init early_init_drmem_lmb(struct drmem_lmb *lmb,
 		}
 
 		DBG("Adding: %llx -> %llx\n", base, size);
-		memblock_add(base, size);
+		if (validate_mem_limit(base, &size))
+			memblock_add(base, size);
 	} while (--rngs);
 }
 #endif /* CONFIG_PPC_PSERIES */
@@ -548,8 +572,10 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 	}
 
 	/* Add the chunk to the MEMBLOCK list */
-	if (add_mem_to_memblock)
-		memblock_add(base, size);
+	if (add_mem_to_memblock) {
+		if (validate_mem_limit(base, &size))
+			memblock_add(base, size);
+	}
 }
 
 static void __init early_reserve_mem_dt(void)
-- 
2.17.1

[PATCH 2/2] powerpc/mm: Increase MAX_PHYSMEM_BITS to 128TB with SPARSEMEM_VMEMMAP config

[Aneesh Kumar K.V]

We do this only with VMEMMAP config so that our page_to_[nid/section] etc are not
impacted.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
 arch/powerpc/include/asm/sparsemem.h | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/sparsemem.h b/arch/powerpc/include/asm/sparsemem.h
index bc66712bdc3c..28f5dae25db6 100644
--- a/arch/powerpc/include/asm/sparsemem.h
+++ b/arch/powerpc/include/asm/sparsemem.h
@@ -6,13 +6,20 @@
 #ifdef CONFIG_SPARSEMEM
 /*
  * SECTION_SIZE_BITS		2^N: how big each section will be
- * MAX_PHYSADDR_BITS		2^N: how much physical address space we have
  * MAX_PHYSMEM_BITS		2^N: how much memory we can have in that space
  */
 #define SECTION_SIZE_BITS       24
-
-#define MAX_PHYSADDR_BITS       46
+/*
+ * If we store section details in page->flags we can't increase the MAX_PHYSMEM_BITS
+ * if we increase SECTIONS_WIDTH we will not store node details in page->flags and
+ * page_to_nid does a page->section->node lookup
+ * Hence only increase for VMEMMAP.
+ */
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+#define MAX_PHYSMEM_BITS        47
+#else
 #define MAX_PHYSMEM_BITS        46
+#endif
 
 #endif /* CONFIG_SPARSEMEM */
 
-- 
2.17.1

Re: [PATCH 2/2] powerpc/mm: Increase MAX_PHYSMEM_BITS to 128TB with SPARSEMEM_VMEMMAP config

[Balbir Singh]

On Thu, Jun 21, 2018 at 6:31 PM, Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> We do this only with VMEMMAP config so that our page_to_[nid/section] etc are not
> impacted.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>

Why 128TB, given that it's sparse_vmemmap_extreme by default, why not
1PB directly (50 bits)?

Balbir Singh

Re: [PATCH 2/2] powerpc/mm: Increase MAX_PHYSMEM_BITS to 128TB with SPARSEMEM_VMEMMAP config

[Aneesh Kumar K.V]

On 06/21/2018 05:02 PM, Balbir Singh wrote:
> On Thu, Jun 21, 2018 at 6:31 PM, Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> We do this only with VMEMMAP config so that our page_to_[nid/section] etc are not
>> impacted.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> 
> Why 128TB, given that it's sparse_vmemmap_extreme by default, why not
> 1PB directly (50 bits)?
> 

That will impact config with VMEMMAP_EXTREME with no real immediate 
benefit. We could possibly make MAX_PHYSMEM_BITS a Kconfig variable. 
s390 do that. Not sure we want to do that.

-aneesh

Re: [PATCH 2/2] powerpc/mm: Increase MAX_PHYSMEM_BITS to 128TB with SPARSEMEM_VMEMMAP config

[Aneesh Kumar K.V]

On 06/21/2018 05:02 PM, Balbir Singh wrote:
> On Thu, Jun 21, 2018 at 6:31 PM, Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> We do this only with VMEMMAP config so that our page_to_[nid/section] etc are not
>> impacted.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> 
> Why 128TB, given that it's sparse_vmemmap_extreme by default, why not
> 1PB directly (50 bits)?
> 

That will impact config with VMEMMAP_EXTREME disabled with no real 
immediate benefit. We could possibly make MAX_PHYSMEM_BITS a Kconfig 
variable. s390 do that. Not sure we want to do that.

-aneesh

Re: [1/2] powerpc/mm: Check memblock_add against MAX_PHYSMEM_BITS range

[Michael Ellerman]

On Thu, 2018-06-21 at 08:31:57 UTC, "Aneesh Kumar K.V" wrote:
> With SPARSEMEM config enabled, we make sure that we don't add sections beyond
> MAX_PHYSMEM_BITS range. This results in not building vmemmap mapping for
> range beyond max range. But our memblock layer looks the device tree and create
> mapping for the full memory range. Prevent this by checking against
> MAX_PHSYSMEM_BITS when doing memblock_add.
> 
> We don't do similar check for memeblock_reserve_range. If reserve range is beyond
> MAX_PHYSMEM_BITS we expect that to be configured with 'nomap'. Any other
> reserved range should come from existing memblock ranges which we already
> filtered while adding.
> 
> This avoids crash as below when running on a system with system ram config above
> MAX_PHSYSMEM_BITS
> 
>  Unable to handle kernel paging request for data at address 0xc00a001000000440
>  Faulting instruction address: 0xc000000001034118
>  cpu 0x0: Vector: 300 (Data Access) at [c00000000124fb30]
>      pc: c000000001034118: __free_pages_bootmem+0xc0/0x1c0
>      lr: c00000000103b258: free_all_bootmem+0x19c/0x22c
>      sp: c00000000124fdb0
>     msr: 9000000002001033
>     dar: c00a001000000440
>   dsisr: 40000000
>    current = 0xc00000000120dd00
>    paca    = 0xc000000001f60000^I irqmask: 0x03^I irq_happened: 0x01
>      pid   = 0, comm = swapper
>  [c00000000124fe20] c00000000103b258 free_all_bootmem+0x19c/0x22c
>  [c00000000124fee0] c000000001010a68 mem_init+0x3c/0x5c
>  [c00000000124ff00] c00000000100401c start_kernel+0x298/0x5e4
>  [c00000000124ff90] c00000000000b57c start_here_common+0x1c/0x520
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/6aba0c84ec474534bbae3675e95464

cheers