Re: Fwd: [Bug 213069] New: kernel BUG at arch/powerpc/include/asm/book3s/64/hash-4k.h:147! Oops: Exception in kernel mode, sig: 5 [#1]

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
         BUG();		------> Failed
         return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
         if (radix_enabled())
                 return radix__pmd_mkhuge(pmd);
         return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
         unsigned long pmdv;

         pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

         return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

- Anshuman

On 5/15/21 7:52 PM, Christophe Leroy wrote:

quoted

------------[ cut here ]------------
kernel BUG at arch/powerpc/include/asm/book3s/64/hash-4k.h:147!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=4 NUMA PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W         5.13.0-rc1-PowerMacG5
#2
NIP:  c00000000003d6fc LR: c000000001024bc8 CTR: c0000000000f778c
REGS: c0000000025f7840 TRAP: 0700   Tainted: G        W
(5.13.0-rc1-PowerMacG5)
MSR:  9000000000029032 <SF,HV,EE,ME,IR,DR,RI>  CR: 44002448  XER: 00000000
IRQMASK: 0
GPR00: c000000001024a5c c0000000025f7ae0 c00000000129f800 c0000000025f7b58
GPR04: 0000000000001000 8000000000000108 0000000000000000 0000000000000001
GPR08: 0000000000000000 0000000000000000 0000000000000008 0000000000000200
GPR12: 0000000024002440 c000000002366000 c00000000001003c 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: c0000000011b3388 c000000000b013e8 c0000000011b3108 4000000000000006
GPR24: 4000000000000280 00000000011b3000 0000000000000000 8000000000000105
GPR28: 0000000000001000 ffffffffffffff7f c000000000b01460 80000000011b3108
NIP [c00000000003d6fc] .pfn_pmd+x0x/0x4
LR [c000000001024bc8] .debug_vm_pgtable+0x3f4/0x51c
Call Trace:
[c0000000025f7ae0] [c000000001024a5c] .debug_vm_pgtable+0x288/0x51c
(unreliable)
[c0000000025f7bd0] [c00000000000fa58] .do_one_initcall+0x104/0x2c4
[c0000000025f7cb0] [c000000001003dec] .kernel_init_freeable+0x3d4/0x410
[c0000000025f7da0] [c00000000001004c] .kernel_init+0x10/0x15c
[c0000000025f7e10] [c00000000000bbf4] .ret_from_kernel_thread+0x58/0x64
Instruction dump:
4bffcd05 60000000 e9210078 e94d0370 7d295279 39400000 4182000c 487d3829
60000000 38210090 7fe3fb78 487dacf4 <0fe00000> 7c0802a6 f8010010 f821ff71
---[ end trace 21fc0fb84dac9a9b ]---

On 5/17/21 11:17 AM, Christophe Leroy wrote:

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
         BUG();        ------> Failed
         return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
         if (radix_enabled())
                 return radix__pmd_mkhuge(pmd);
         return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
         unsigned long pmdv;

         pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

         return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

	if (!has_transparent_hugepage())
		return;


On hash with 4K page size, we can't support leaf page table entry and 
PMD and PUD level. Hence we don't support THP for them.

-aneesh

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
         BUG();        ------> Failed
         return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
         if (radix_enabled())
                 return radix__pmd_mkhuge(pmd);
         return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
         unsigned long pmdv;

         pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

         return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

    if (!has_transparent_hugepage())
        return;


On hash with 4K page size, we can't support leaf page table entry and PMD and PUD level. Hence we don't support THP for them.

But could CONFIG_TRANSPARENT_HUGEPAGE be enabled on such configs ?
Otherwise, wondering how the BUG() just got triggered there.

On 5/17/21 12:55 PM, Anshuman Khandual wrote:

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
          BUG();        ------> Failed
          return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
          if (radix_enabled())
                  return radix__pmd_mkhuge(pmd);
          return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
          unsigned long pmdv;

          pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

          return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

     if (!has_transparent_hugepage())
         return;


On hash with 4K page size, we can't support leaf page table entry and PMD and PUD level. Hence we don't support THP for them.

But could CONFIG_TRANSPARENT_HUGEPAGE be enabled on such configs ?
Otherwise, wondering how the BUG() just got triggered there.

yes. We do support THP with radix translation and 4K page size.

-aneesh

On 5/17/21 1:14 PM, Aneesh Kumar K.V wrote:

On 5/17/21 12:55 PM, Anshuman Khandual wrote:

quoted

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
          BUG();        ------> Failed
          return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
          if (radix_enabled())
                  return radix__pmd_mkhuge(pmd);
          return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
          unsigned long pmdv;

          pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

          return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

     if (!has_transparent_hugepage())
         return;


On hash with 4K page size, we can't support leaf page table entry and PMD and PUD level. Hence we don't support THP for them.

But could CONFIG_TRANSPARENT_HUGEPAGE be enabled on such configs ?
Otherwise, wondering how the BUG() just got triggered there.

yes. We do support THP with radix translation and 4K page size.

I was actually wondering about whether 4K page size in hash config
supports THP and could enable CONFIG_TRANSPARENT_HUGEPAGE ? But as
there is a BUG() trigger on hash__pmd_mkhuge(), it seems like THP
config should not have been enabled for such platforms but it does
for some reason. Could not we disable it ?

On 5/17/21 4:23 PM, Anshuman Khandual wrote:

On 5/17/21 1:14 PM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 12:55 PM, Anshuman Khandual wrote:

quoted

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
           BUG();        ------> Failed
           return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
           if (radix_enabled())
                   return radix__pmd_mkhuge(pmd);
           return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
           unsigned long pmdv;

           pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

           return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

      if (!has_transparent_hugepage())
          return;


On hash with 4K page size, we can't support leaf page table entry and PMD and PUD level. Hence we don't support THP for them.

But could CONFIG_TRANSPARENT_HUGEPAGE be enabled on such configs ?
Otherwise, wondering how the BUG() just got triggered there.

yes. We do support THP with radix translation and 4K page size.

I was actually wondering about whether 4K page size in hash config
supports THP and could enable CONFIG_TRANSPARENT_HUGEPAGE ? But as
there is a BUG() trigger on hash__pmd_mkhuge(), it seems like THP
config should not have been enabled for such platforms but it does
for some reason. Could not we disable it ?

Hash is a translation mode which is not build time selected. Rather it 
is runtime selected. Same kernel can boot into either hash or radix 
translation. We don't support THP with 4K pagesize with hash 
translation.But the same kernel when booted in radix translation mode 
will support THP.

-aneesh

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
         BUG();        ------> Failed
         return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
         if (radix_enabled())
                 return radix__pmd_mkhuge(pmd);
         return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
         unsigned long pmdv;

         pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

         return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

    if (!has_transparent_hugepage())
        return;

The following patch has been lightly tested on arm64 and x86 platforms.
Could you please verify if this solves the problem on powerpc 4K hash
config ? Thank you.

- Anshuman

 mm/debug_vm_pgtable.c | 58 +++++++++++++++++++++++++++++++++++--------
 1 file changed, 48 insertions(+), 10 deletions(-)

diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index e2f35db8ba69..6ff92c8b0a00 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c

@@ -146,13 +146,14 @@ static void __init pte_savedwrite_tests(unsigned long pfn, pgprot_t prot)
 static void __init pmd_basic_tests(unsigned long pfn, int idx)
 {
 	pgprot_t prot = protection_map[idx];
-	pmd_t pmd = pfn_pmd(pfn, prot);
 	unsigned long val = idx, *ptr = &val;
+	pmd_t pmd;
 
 	if (!has_transparent_hugepage())
 		return;
 
 	pr_debug("Validating PMD basic (%pGv)\n", ptr);
+	pmd = pfn_pmd(pfn, prot);
 
 	/*
 	 * This test needs to be executed after the given page table entry

@@ -232,9 +233,14 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,
 
 static void __init pmd_leaf_tests(unsigned long pfn, pgprot_t prot)
 {
-	pmd_t pmd = pfn_pmd(pfn, prot);
+	pmd_t pmd;
+
+	if (!has_transparent_hugepage())
+		return;
 
 	pr_debug("Validating PMD leaf\n");
+	pmd = pfn_pmd(pfn, prot);
+
 	/*
 	 * PMD based THP is a leaf entry.
 	 */

@@ -244,12 +250,16 @@ static void __init pmd_leaf_tests(unsigned long pfn, pgprot_t prot)
 
 static void __init pmd_savedwrite_tests(unsigned long pfn, pgprot_t prot)
 {
-	pmd_t pmd = pfn_pmd(pfn, prot);
+	pmd_t pmd;
 
 	if (!IS_ENABLED(CONFIG_NUMA_BALANCING))
 		return;
 
+	if (!has_transparent_hugepage())
+		return;
+
 	pr_debug("Validating PMD saved write\n");
+	pmd = pfn_pmd(pfn, prot);
 	WARN_ON(!pmd_savedwrite(pmd_mk_savedwrite(pmd_clear_savedwrite(pmd))));
 	WARN_ON(pmd_savedwrite(pmd_clear_savedwrite(pmd_mk_savedwrite(pmd))));
 }

@@ -258,13 +268,14 @@ static void __init pmd_savedwrite_tests(unsigned long pfn, pgprot_t prot)
 static void __init pud_basic_tests(struct mm_struct *mm, unsigned long pfn, int idx)
 {
 	pgprot_t prot = protection_map[idx];
-	pud_t pud = pfn_pud(pfn, prot);
 	unsigned long val = idx, *ptr = &val;
+	pud_t pud;
 
 	if (!has_transparent_hugepage())
 		return;
 
 	pr_debug("Validating PUD basic (%pGv)\n", ptr);
+	pud = pfn_pud(pfn, prot);
 
 	/*
 	 * This test needs to be executed after the given page table entry

@@ -348,9 +359,13 @@ static void __init pud_advanced_tests(struct mm_struct *mm,
 
 static void __init pud_leaf_tests(unsigned long pfn, pgprot_t prot)
 {
-	pud_t pud = pfn_pud(pfn, prot);
+	pud_t pud;
+
+	if (!has_transparent_hugepage())
+		return;
 
 	pr_debug("Validating PUD leaf\n");
+	pud = pfn_pud(pfn, prot);
 	/*
 	 * PUD based THP is a leaf entry.
 	 */

@@ -642,12 +657,16 @@ static void __init pte_protnone_tests(unsigned long pfn, pgprot_t prot)
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static void __init pmd_protnone_tests(unsigned long pfn, pgprot_t prot)
 {
-	pmd_t pmd = pmd_mkhuge(pfn_pmd(pfn, prot));
+	pmd_t pmd;
 
 	if (!IS_ENABLED(CONFIG_NUMA_BALANCING))
 		return;
 
+	if (!has_transparent_hugepage())
+		return;
+
 	pr_debug("Validating PMD protnone\n");
+	pmd = pmd_mkhuge(pfn_pmd(pfn, prot));
 	WARN_ON(!pmd_protnone(pmd));
 	WARN_ON(!pmd_present(pmd));
 }

@@ -667,18 +686,26 @@ static void __init pte_devmap_tests(unsigned long pfn, pgprot_t prot)
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static void __init pmd_devmap_tests(unsigned long pfn, pgprot_t prot)
 {
-	pmd_t pmd = pfn_pmd(pfn, prot);
+	pmd_t pmd;
+
+	if (!has_transparent_hugepage())
+		return;
 
 	pr_debug("Validating PMD devmap\n");
+	pmd = pfn_pmd(pfn, prot);
 	WARN_ON(!pmd_devmap(pmd_mkdevmap(pmd)));
 }
 
 #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
 static void __init pud_devmap_tests(unsigned long pfn, pgprot_t prot)
 {
-	pud_t pud = pfn_pud(pfn, prot);
+	pud_t pud;
+
+	if (!has_transparent_hugepage())
+		return;
 
 	pr_debug("Validating PUD devmap\n");
+	pud = pfn_pud(pfn, prot);
 	WARN_ON(!pud_devmap(pud_mkdevmap(pud)));
 }
 #else  /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */

@@ -721,25 +748,33 @@ static void __init pte_swap_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static void __init pmd_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
 {
-	pmd_t pmd = pfn_pmd(pfn, prot);
+	pmd_t pmd;
 
 	if (!IS_ENABLED(CONFIG_MEM_SOFT_DIRTY))
 		return;
 
+	if (!has_transparent_hugepage())
+		return;
+
 	pr_debug("Validating PMD soft dirty\n");
+	pmd = pfn_pmd(pfn, prot);
 	WARN_ON(!pmd_soft_dirty(pmd_mksoft_dirty(pmd)));
 	WARN_ON(pmd_soft_dirty(pmd_clear_soft_dirty(pmd)));
 }
 
 static void __init pmd_swap_soft_dirty_tests(unsigned long pfn, pgprot_t prot)
 {
-	pmd_t pmd = pfn_pmd(pfn, prot);
+	pmd_t pmd;
 
 	if (!IS_ENABLED(CONFIG_MEM_SOFT_DIRTY) ||
 		!IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION))
 		return;
 
+	if (!has_transparent_hugepage())
+		return;
+
 	pr_debug("Validating PMD swap soft dirty\n");
+	pmd = pfn_pmd(pfn, prot);
 	WARN_ON(!pmd_swp_soft_dirty(pmd_swp_mksoft_dirty(pmd)));
 	WARN_ON(pmd_swp_soft_dirty(pmd_swp_clear_soft_dirty(pmd)));
 }

@@ -768,6 +803,9 @@ static void __init pmd_swap_tests(unsigned long pfn, pgprot_t prot)
 	swp_entry_t swp;
 	pmd_t pmd;
 
+	if (!has_transparent_hugepage())
+		return;
+
 	pr_debug("Validating PMD swap\n");
 	pmd = pfn_pmd(pfn, prot);
 	swp = __pmd_to_swp_entry(pmd);

-- 
2.20.1

Le 17/05/2021 à 14:49, Anshuman Khandual a écrit :

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
          BUG();        ------> Failed
          return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
          if (radix_enabled())
                  return radix__pmd_mkhuge(pmd);
          return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
          unsigned long pmdv;

          pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

          return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

     if (!has_transparent_hugepage())
         return;

The following patch has been lightly tested on arm64 and x86 platforms.
Could you please verify if this solves the problem on powerpc 4K hash
config ? Thank you.

No need to update pmd_advanced_tests() and pud_advanced_tests() ?

Christophe

On 5/17/21 6:29 PM, Christophe Leroy wrote:

Le 17/05/2021 à 14:49, Anshuman Khandual a écrit :

quoted

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
          BUG();        ------> Failed
          return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
          if (radix_enabled())
                  return radix__pmd_mkhuge(pmd);
          return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
          unsigned long pmdv;

          pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

          return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

     if (!has_transparent_hugepage())
         return;

The following patch has been lightly tested on arm64 and x86 platforms.
Could you please verify if this solves the problem on powerpc 4K hash
config ? Thank you.

No need to update pmd_advanced_tests() and pud_advanced_tests() ?

They already have has_transparent_hugepage() check and all pfn_pxx()
instances are after that check. Do you see any other concern ?

Christophe

Anshuman Khandual [off-list ref] writes:

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
         BUG();        ------> Failed
         return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
         if (radix_enabled())
                 return radix__pmd_mkhuge(pmd);
         return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
         unsigned long pmdv;

         pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

         return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

    if (!has_transparent_hugepage())
        return;

The following patch has been lightly tested on arm64 and x86 platforms.
Could you please verify if this solves the problem on powerpc 4K hash
config ? Thank you.

Tested the patch with the below additional change.

modified   mm/debug_vm_pgtable.c

@@ -186,12 +186,13 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,
 				      unsigned long pfn, unsigned long vaddr,
 				      pgprot_t prot, pgtable_t pgtable)
 {
-	pmd_t pmd = pfn_pmd(pfn, prot);
+	pmd_t pmd;
 
 	if (!has_transparent_hugepage())
 		return;
 
 	pr_debug("Validating PMD advanced\n");
+	pmd = pfn_pmd(pfn, prot);
 	/* Align the address wrt HPAGE_PMD_SIZE */
 	vaddr = (vaddr & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE;
 

@@ -334,12 +335,13 @@ static void __init pud_advanced_tests(struct mm_struct *mm,
 				      unsigned long pfn, unsigned long vaddr,
 				      pgprot_t prot)
 {
-	pud_t pud = pfn_pud(pfn, prot);
+	pud_t pud;
 
 	if (!has_transparent_hugepage())
 		return;
 
 	pr_debug("Validating PUD advanced\n");
+	pud = pfn_pud(pfn, prot);
 	/* Align the address wrt HPAGE_PUD_SIZE */
 	vaddr = (vaddr & HPAGE_PUD_MASK) + HPAGE_PUD_SIZE;
 



-aneesh

On 5/17/21 7:22 PM, Aneesh Kumar K.V wrote:

Right. But this change is already on the linux-next (20210514) via another
commit ae7920ce9e9bb ("mm/debug_vm_pgtable: remove redundant pfn_{pmd/pte}()
and fix one comment mistake") which got queued recently. Anyways, now that
we have verified the fix, will send it out against linux-next soon.

Le 17/05/2021 à 15:12, Anshuman Khandual a écrit :

On 5/17/21 6:29 PM, Christophe Leroy wrote:

quoted

Le 17/05/2021 à 14:49, Anshuman Khandual a écrit :

quoted

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:

quoted

On 5/17/21 11:17 AM, Christophe Leroy wrote:

quoted

+aneesh
+linuxppc-dev list

Le 17/05/2021 à 07:44, Anshuman Khandual a écrit :

quoted

Hello Christophe,

DEBUG_VM_PGTABLE has now been re-enabled on powerpc recently ? was not
aware about this. From the error log, it failed explicitly on 4K page
size hash config.

static inline pmd_t hash__pmd_mkhuge(pmd_t pmd)
{
           BUG();        ------> Failed
           return pmd;
}

static inline pmd_t __pmd_mkhuge(pmd_t pmd)
{
           if (radix_enabled())
                   return radix__pmd_mkhuge(pmd);
           return hash__pmd_mkhuge(pmd);
}

pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot)
{
           unsigned long pmdv;

           pmdv = (pfn << PAGE_SHIFT) & PTE_RPN_MASK;

           return __pmd_mkhuge(pmd_set_protbits(__pmd(pmdv), pgprot));
}

It seems like on powerpc, where pfn_pmd() makes a huge page but which
is not supported on 4K hash config thus triggering the BUG(). But all
pfn_pmd() call sites inside the debug_vm_pgtable() test are protected
with CONFIG_TRANSPARENT_HUGEPAGE. IIUC unlike powerpc, pfn_pmd() does
not directly make a huge page on other platforms.

Looking at arch/powerpc/include/asm/book3s/64/hash-4k.h, all relevant
THP helpers has BUG() or 0 which indicates THP might not be supported
on 4K page size hash config ?

But looking at arch/powerpc/platforms/Kconfig.cputype, it seems like
HAVE_ARCH_TRANSPARENT_HUGEPAGE is invariably selected on PPC_BOOK3S_64
platforms which I assume includes 4K page size hash config as well.

Is THP some how getting enabled on this 4K page size hash config where
it should not be (thus triggering the BUG) ? OR am I missing something
here.

We should put those  pfn_pmd()  and pfn_pud() after

      if (!has_transparent_hugepage())
          return;

The following patch has been lightly tested on arm64 and x86 platforms.
Could you please verify if this solves the problem on powerpc 4K hash
config ? Thank you.

No need to update pmd_advanced_tests() and pud_advanced_tests() ?

They already have has_transparent_hugepage() check and all pfn_pxx()
instances are after that check. Do you see any other concern ?

As far as I can see, in 5.13-rc2 they are before the check :

https://elixir.bootlin.com/linux/v5.13-rc2/source/mm/debug_vm_pgtable.c#L183

Christophe