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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

            Bug ID: 213069
           Summary: kernel BUG at
                    arch/powerpc/include/asm/book3s/64/hash-4k.h:147!
                    Oops: Exception in kernel mode, sig: 5 [#1]
           Product: Platform Specific/Hardware
           Version: 2.5
    Kernel Version: 5.13-rc1
          Hardware: PPC-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: PPC-64
          Assignee: platform_ppc-64@kernel-bugs.osdl.org
          Reporter: erhard_f@mailbox.org
        Regression: No

Created attachment 296753
  --> https://bugzilla.kernel.org/attachment.cgi?id=296753&action=edit
kernel .config (5.13-rc1, PowerMac G5 11,2)

Got this on my PowerMac G5 11,2 with v5.13-rc1 + few debug options on. The bug
was too early for netconsole to kick in so I took a photo and transcribed it.

[...]
kmemleak: Kernel memory leak detector initialized (mem pool available: 15805)
kmemleak: Automatic memory scanning thread started
debug_vm_pgtable: [debug_vm_pgtable         ]: Validating architecture page
table helpers
------------[ 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 ]---

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000005
Rebooting in 120 seconds..

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
The bug occurs with DEBUG_VM_PGTABLE=y. When DEBUG_VM_PGTABLE is not set the
kernel boots fine.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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]

[Christophe Leroy]

+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:
>> ------------[ 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 ]---

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 Kumar K.V]

On 5/17/21 11:17 AM, Christophe Leroy wrote:
> +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.
>>
>

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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

Christophe Leroy (christophe.leroy@csgroup.eu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christophe.leroy@csgroup.eu

--- Comment #2 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
The bug is not in powerpc but in function pmd_basic_tests() in
mm/debug_vm_pgtable.c
(https://elixir.bootlin.com/linux/v5.13-rc1/source/mm/debug_vm_pgtable.c#L146)

pfn_pmd() should not be called before the has_transparent_hugepage()
verification.

Same problem in pmd_advanced_tests()

And there is the exact same issue with PUD tests with pfn_pud() function.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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]

[Anshuman Khandual]

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>> +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.
>>>
>>
> 
> 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.

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 Kumar K.V]

On 5/17/21 12:55 PM, Anshuman Khandual wrote:
> 
> 
> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>> +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.
>>>>
>>>
>>
>> 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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

Michael Ellerman (michael@ellerman.id.au) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |michael@ellerman.id.au

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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]

[Anshuman Khandual]

On 5/17/21 1:14 PM, Aneesh Kumar K.V wrote:
> On 5/17/21 12:55 PM, Anshuman Khandual wrote:
>>
>>
>> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>>> +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.
>>>>>
>>>>
>>>
>>> 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 ?

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 Kumar K.V]

On 5/17/21 4:23 PM, Anshuman Khandual wrote:
> 
> 
> On 5/17/21 1:14 PM, Aneesh Kumar K.V wrote:
>> On 5/17/21 12:55 PM, Anshuman Khandual wrote:
>>>
>>>
>>> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>>>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>>>> +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.
>>>>>>
>>>>>
>>>>
>>>> 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

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]

[Anshuman Khandual]

On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>> +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.
>>>
>>
> 
> 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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

--- Comment #3 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
Patch proposed by Anshuman, to be tested:

https://lore.kernel.org/linuxppc-dev/bug-213069-206035@https.bugzilla.kernel.org%2F/T/#m82f2974b813c4d3a085b0cd2ac3d5b732a362e68

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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]

[Christophe Leroy]

Le 17/05/2021 à 14:49, Anshuman Khandual a écrit :
> 
> 
> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>> +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.
>>>>
>>>
>>
>> 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

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]

[Anshuman Khandual]

On 5/17/21 6:29 PM, Christophe Leroy wrote:
> 
> 
> Le 17/05/2021 à 14:49, Anshuman Khandual a écrit :
>>
>>
>> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>>> +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.
>>>>>
>>>>
>>>
>>> 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

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 Kumar K.V]

Anshuman Khandual <anshuman.khandual@arm.com> writes:

> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>> +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.
>>>>
>>>
>> 
>> 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

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]

[Anshuman Khandual]

On 5/17/21 7:22 PM, Aneesh Kumar K.V wrote:
> Anshuman Khandual <anshuman.khandual@arm.com> writes:
> 
>> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>>> +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.
>>>>>
>>>>
>>>
>>> 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;
>  

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.

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]

[Christophe Leroy]

Le 17/05/2021 à 15:12, Anshuman Khandual a écrit :
> 
> 
> On 5/17/21 6:29 PM, Christophe Leroy wrote:
>>
>>
>> Le 17/05/2021 à 14:49, Anshuman Khandual a écrit :
>>>
>>>
>>> On 5/17/21 11:25 AM, Aneesh Kumar K.V wrote:
>>>> On 5/17/21 11:17 AM, Christophe Leroy wrote:
>>>>> +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.
>>>>>>
>>>>>
>>>>
>>>> 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

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

Michael Ellerman (michael@ellerman.id.au) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |CODE_FIX

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|CODE_FIX                    |---

--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
I applied the patch on top of 5.13-rc4 but it didn't work out unfortunately.

Still getting the same
kernel BUG at arch/powerpc/include/asm/book3s/64/hash-4k.h:147!
Oops: Exception in kernel mode, sig: 5 [#1]
...

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=213069

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |PATCH_ALREADY_AVAILABLE

--- Comment #5 from Erhard F. (erhard_f@mailbox.org) ---
Works now with Anshuman's patch applied:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c0dd65c2e295762fc5ebd11f8da3ac33f1d30788

Thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.