Re: powerpc: booke: fix boot crash due to null hugepd

2017-03-07 Thread Michael Ellerman 
On Thu, 2017-02-16 at 15:11:29 UTC, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> On 32-bit book-e machines, hugepd_ok() does not take
> into account null hugepd values, causing this crash at boot:
> 
> Unable to handle kernel paging request for data at address 0x8000
> Faulting instruction address: 0xc00182a8
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=24
> CoreNet Generic
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   
> 4.10.0-rc8-00016-g69b1f87 #11
> task: e505 task.stack: e5058000
> NIP: c00182a8 LR: c001829c CTR: 7ffe
> REGS: e5059c50 TRAP: 0300   Tainted: GW
> (4.10.0-rc8-00016-g69b1f87)
> MSR: 00021002 
>   CR: 88428e82  XER: 
> DEAR: 8000 ESR: 
> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 2017
> GPR08:     28428e82  c00027d0 
> GPR16:   88a28e82 2000 48422e82  88a28e84 dd004000
> GPR24: e5059e38   bff1 dd004000 0001 00029002 bff1
> NIP [c00182a8] follow_huge_addr+0x38/0xf0
> LR [c001829c] follow_huge_addr+0x2c/0xf0
> Call Trace:
> [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
> [e5059e30] [c013f170] copy_strings+0x110/0x3a0
> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
> [e5059f10] [c01414fc] do_execve+0x2c/0x40
> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
> [e5059f30] [c000289c] kernel_init+0xcc/0x120
> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89
> ---[ end trace 4bf94e15fd9fa824 ]---
> 
> This impacts all nxp (ex-freescale) 32-bit booke platforms.
> 
> Fixes: 20717e1ff526 ("powerpc/mm: Fix little-endian 4K hugetlb")
> 
> Reported-by: Madalin-Cristian Bucur 
> Signed-off-by: Laurentiu Tudor 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/3fb66a70a4ae886445743354e4b60e

cheers

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-03-01 Thread Michael Ellerman 
Scott Wood  writes:

> On Tue, 2017-02-28 at 14:55 +, Laurentiu Tudor wrote:
>> On 02/17/2017 02:18 PM, Aneesh Kumar K.V wrote:
>> > laurentiu.tu...@nxp.com writes:
>> > > From: Laurentiu Tudor 
>> > > 
>> > > On 32-bit book-e machines, hugepd_ok() does not take
>> > > into account null hugepd values, causing this crash at boot:
>> > > 
>> > > Unable to handle kernel paging request for data at address 0x8000
>> > > Faulting instruction address: 0xc00182a8
>> > > Oops: Kernel access of bad area, sig: 11 [#1]
>> > > SMP NR_CPUS=24
>> > > CoreNet Generic
>> > > Modules linked in:
>> > > CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   4.10.0-rc8-
>> > > 00016-g69b1f87 #11
>> > > task: e505 task.stack: e5058000
>> > > NIP: c00182a8 LR: c001829c CTR: 7ffe
>> > > REGS: e5059c50 TRAP: 0300   Tainted: GW(4.10.0-rc8-
>> > > 00016-g69b1f87)
>> > > MSR: 00021002 
>> > >    CR: 88428e82  XER: 
>> > > DEAR: 8000 ESR: 
>> > > GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08
>> > > 2017
>> > > GPR08:     28428e82  c00027d0
>> > > 
>> > > GPR16:   88a28e82 2000 48422e82  88a28e84
>> > > dd004000
>> > > GPR24: e5059e38   bff1 dd004000 0001 00029002
>> > > bff1
>> > > NIP [c00182a8] follow_huge_addr+0x38/0xf0
>> > > LR [c001829c] follow_huge_addr+0x2c/0xf0
>> > > Call Trace:
>> > > [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
>> > > [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
>> > > [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
>> > > [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
>> > > [e5059e30] [c013f170] copy_strings+0x110/0x3a0
>> > > [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
>> > > [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
>> > > [e5059f10] [c01414fc] do_execve+0x2c/0x40
>> > > [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
>> > > [e5059f30] [c000289c] kernel_init+0xcc/0x120
>> > > [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
>> > > Instruction dump:
>> > > bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
>> > > 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea
>> > > 2f89
>> > > ---[ end trace 4bf94e15fd9fa824 ]---
>> > 
>> > Which code path is that. That null should be filtered by the if
>> > (pmd_none(pmd)) check in find_linux_pte_or_hugepte right ?
>> The crash happens when __find_linux_pte_or_hugepte() calls hugepd_ok(),
>> on this line [1]. It's triggered when __find_linux_pte_or_hugepte() is
>> first called, when the kernel tries to spawn the init process. The input
>> effective address (ea arg) is bff1. This is the call stack:
>
> What is the pmd value?  There's a pmd_none() check before that line.

It's a pgd, so a pgd_none() check.

But that does nothing because this is 32-bit, 4K PAGE_SIZE, which uses
pgtable-nopmd.h and pgtable-nopud.h, so pgd_none() is just:

  int pgd_none(pgd_t pgd) { return 0; }

> That said, regardless of what's going wrong here, it would be simpler and more
> robust if is_hugepd() returned false for empty ptes rather than assuming the
> caller explicitly checked pmd_none().

Yeah, in fact it has to, because of the above.

So Laurentiu's patch is pretty much the correct fix.

cheers

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-02-28 Thread Scott Wood 
On Tue, 2017-02-28 at 14:55 +, Laurentiu Tudor wrote:
> Hi,
> 
> Some more information on the crash, inline.
> 
> On 02/17/2017 02:18 PM, Aneesh Kumar K.V wrote:
> > 
> > laurentiu.tu...@nxp.com writes:
> > 
> > > 
> > > From: Laurentiu Tudor 
> > > 
> > > On 32-bit book-e machines, hugepd_ok() does not take
> > > into account null hugepd values, causing this crash at boot:
> > > 
> > > Unable to handle kernel paging request for data at address 0x8000
> > > Faulting instruction address: 0xc00182a8
> > > Oops: Kernel access of bad area, sig: 11 [#1]
> > > SMP NR_CPUS=24
> > > CoreNet Generic
> > > Modules linked in:
> > > CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   4.10.0-rc8-
> > > 00016-g69b1f87 #11
> > > task: e505 task.stack: e5058000
> > > NIP: c00182a8 LR: c001829c CTR: 7ffe
> > > REGS: e5059c50 TRAP: 0300   Tainted: GW(4.10.0-rc8-
> > > 00016-g69b1f87)
> > > MSR: 00021002 
> > >    CR: 88428e82  XER: 
> > > DEAR: 8000 ESR: 
> > > GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08
> > > 2017
> > > GPR08:     28428e82  c00027d0
> > > 
> > > GPR16:   88a28e82 2000 48422e82  88a28e84
> > > dd004000
> > > GPR24: e5059e38   bff1 dd004000 0001 00029002
> > > bff1
> > > NIP [c00182a8] follow_huge_addr+0x38/0xf0
> > > LR [c001829c] follow_huge_addr+0x2c/0xf0
> > > Call Trace:
> > > [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
> > > [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
> > > [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
> > > [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
> > > [e5059e30] [c013f170] copy_strings+0x110/0x3a0
> > > [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
> > > [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
> > > [e5059f10] [c01414fc] do_execve+0x2c/0x40
> > > [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
> > > [e5059f30] [c000289c] kernel_init+0xcc/0x120
> > > [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
> > > Instruction dump:
> > > bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
> > > 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea
> > > 2f89
> > > ---[ end trace 4bf94e15fd9fa824 ]---
> > 
> > Which code path is that. That null should be filtered by the if
> > (pmd_none(pmd)) check in find_linux_pte_or_hugepte right ?
> The crash happens when __find_linux_pte_or_hugepte() calls hugepd_ok(),
> on this line [1]. It's triggered when __find_linux_pte_or_hugepte() is
> first called, when the kernel tries to spawn the init process. The input
> effective address (ea arg) is bff1. This is the call stack:

What is the pmd value?  There's a pmd_none() check before that line.

That said, regardless of what's going wrong here, it would be simpler and more
robust if is_hugepd() returned false for empty ptes rather than assuming the
caller explicitly checked pmd_none().

-Scott

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-02-28 Thread Laurentiu Tudor 
Hi,

Some more information on the crash, inline.

On 02/17/2017 02:18 PM, Aneesh Kumar K.V wrote:
> laurentiu.tu...@nxp.com writes:
>
>> From: Laurentiu Tudor 
>>
>> On 32-bit book-e machines, hugepd_ok() does not take
>> into account null hugepd values, causing this crash at boot:
>>
>> Unable to handle kernel paging request for data at address 0x8000
>> Faulting instruction address: 0xc00182a8
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=24
>> CoreNet Generic
>> Modules linked in:
>> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   
>> 4.10.0-rc8-00016-g69b1f87 #11
>> task: e505 task.stack: e5058000
>> NIP: c00182a8 LR: c001829c CTR: 7ffe
>> REGS: e5059c50 TRAP: 0300   Tainted: GW
>> (4.10.0-rc8-00016-g69b1f87)
>> MSR: 00021002 
>>CR: 88428e82  XER: 
>> DEAR: 8000 ESR: 
>> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 
>> 2017
>> GPR08:     28428e82  c00027d0 
>> 
>> GPR16:   88a28e82 2000 48422e82  88a28e84 
>> dd004000
>> GPR24: e5059e38   bff1 dd004000 0001 00029002 
>> bff1
>> NIP [c00182a8] follow_huge_addr+0x38/0xf0
>> LR [c001829c] follow_huge_addr+0x2c/0xf0
>> Call Trace:
>> [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
>> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
>> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
>> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
>> [e5059e30] [c013f170] copy_strings+0x110/0x3a0
>> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
>> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
>> [e5059f10] [c01414fc] do_execve+0x2c/0x40
>> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
>> [e5059f30] [c000289c] kernel_init+0xcc/0x120
>> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
>> Instruction dump:
>> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
>> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89
>> ---[ end trace 4bf94e15fd9fa824 ]---
>
>
> Which code path is that. That null should be filtered by the if
> (pmd_none(pmd)) check in find_linux_pte_or_hugepte right ?

The crash happens when __find_linux_pte_or_hugepte() calls hugepd_ok(),
on this line [1]. It's triggered when __find_linux_pte_or_hugepte() is
first called, when the kernel tries to spawn the init process. The input
effective address (ea arg) is bff1. This is the call stack:

[e5059cd0] [c0017b60] __find_linux_pte_or_hugepte+0x60/0x120 (unreliable)
[e5059d00] [c001832c] follow_huge_addr+0x2c/0xf0
[e5059d20] [c0107590] follow_page_mask+0x40/0x3c0
[e5059d80] [c01079d8] __get_user_pages+0xc8/0x420
[e5059de0] [c01081fc] get_user_pages_remote+0x8c/0x230
[e5059e30] [c013f210] copy_strings+0x110/0x3a0
[e5059ea0] [c013f4cc] copy_strings_kernel+0x2c/0x50
[e5059ec0] [c01413c4] do_execveat_common+0x474/0x620
[e5059f10] [c014159c] do_execve+0x2c/0x40
[e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
[e5059f30] [c000289c] kernel_init+0xcc/0x120
[e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64

Thanks in advance for any pointers.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/mm/hugetlbpage.c#n918

---
Best Regards, Laurentiu

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-02-17 Thread Laurentiu Tudor 


On 02/17/2017 02:18 PM, Aneesh Kumar K.V wrote:
> laurentiu.tu...@nxp.com writes:
>
>> From: Laurentiu Tudor 
>>
>> On 32-bit book-e machines, hugepd_ok() does not take
>> into account null hugepd values, causing this crash at boot:
>>
>> Unable to handle kernel paging request for data at address 0x8000
>> Faulting instruction address: 0xc00182a8
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=24
>> CoreNet Generic
>> Modules linked in:
>> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   
>> 4.10.0-rc8-00016-g69b1f87 #11
>> task: e505 task.stack: e5058000
>> NIP: c00182a8 LR: c001829c CTR: 7ffe
>> REGS: e5059c50 TRAP: 0300   Tainted: GW
>> (4.10.0-rc8-00016-g69b1f87)
>> MSR: 00021002 
>>CR: 88428e82  XER: 
>> DEAR: 8000 ESR: 
>> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 
>> 2017
>> GPR08:     28428e82  c00027d0 
>> 
>> GPR16:   88a28e82 2000 48422e82  88a28e84 
>> dd004000
>> GPR24: e5059e38   bff1 dd004000 0001 00029002 
>> bff1
>> NIP [c00182a8] follow_huge_addr+0x38/0xf0
>> LR [c001829c] follow_huge_addr+0x2c/0xf0
>> Call Trace:
>> [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
>> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
>> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
>> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
>> [e5059e30] [c013f170] copy_strings+0x110/0x3a0
>> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
>> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
>> [e5059f10] [c01414fc] do_execve+0x2c/0x40
>> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
>> [e5059f30] [c000289c] kernel_init+0xcc/0x120
>> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
>> Instruction dump:
>> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
>> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89
>> ---[ end trace 4bf94e15fd9fa824 ]---
>
>
> Which code path is that. That null should be filtered by the if
> (pmd_none(pmd)) check in find_linux_pte_or_hugepte right ?
>

I haven't characterized the issue in detail as i wanted to get the patch 
out ASAP.
I only noticed that the previous check, that is:

"signed hpd_val > 0"

vs the new one, that is:

"unsigned hpd_val & PD_HUGE == 0"

evaluate differently for a value of zero: old expression evaluates
to false and the new one to true.

---
Best Regards, Laurentiu

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-02-17 Thread Aneesh Kumar K.V 
laurentiu.tu...@nxp.com writes:

> From: Laurentiu Tudor 
>
> On 32-bit book-e machines, hugepd_ok() does not take
> into account null hugepd values, causing this crash at boot:
>
> Unable to handle kernel paging request for data at address 0x8000
> Faulting instruction address: 0xc00182a8
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=24
> CoreNet Generic
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   
> 4.10.0-rc8-00016-g69b1f87 #11
> task: e505 task.stack: e5058000
> NIP: c00182a8 LR: c001829c CTR: 7ffe
> REGS: e5059c50 TRAP: 0300   Tainted: GW
> (4.10.0-rc8-00016-g69b1f87)
> MSR: 00021002 
>   CR: 88428e82  XER: 
> DEAR: 8000 ESR: 
> GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 2017
> GPR08:     28428e82  c00027d0 
> GPR16:   88a28e82 2000 48422e82  88a28e84 dd004000
> GPR24: e5059e38   bff1 dd004000 0001 00029002 bff1
> NIP [c00182a8] follow_huge_addr+0x38/0xf0
> LR [c001829c] follow_huge_addr+0x2c/0xf0
> Call Trace:
> [e5059d00] [e5059d00] 0xe5059d00 (unreliable)
> [e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
> [e5059d80] [c0107958] __get_user_pages+0xc8/0x420
> [e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
> [e5059e30] [c013f170] copy_strings+0x110/0x3a0
> [e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
> [e5059ec0] [c0141324] do_execveat_common+0x474/0x620
> [e5059f10] [c01414fc] do_execve+0x2c/0x40
> [e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
> [e5059f30] [c000289c] kernel_init+0xcc/0x120
> [e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
> 4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89
> ---[ end trace 4bf94e15fd9fa824 ]---


Which code path is that. That null should be filtered by the if
(pmd_none(pmd)) check in find_linux_pte_or_hugepte right ?

>
> This impacts all nxp (ex-freescale) 32-bit booke platforms.
>
> Fixes: 20717e1ff526 ("powerpc/mm: Fix little-endian 4K hugetlb")
>
> Reported-by: Madalin-Cristian Bucur 
> Signed-off-by: Laurentiu Tudor 
> ---
>  arch/powerpc/include/asm/nohash/pgtable.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h 
> b/arch/powerpc/include/asm/nohash/pgtable.h
> index 0cd8a38..e5805ad 100644
> --- a/arch/powerpc/include/asm/nohash/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> @@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd)
>   return ((hpd_val(hpd) & 0x4) != 0);
>  #else
>   /* We clear the top bit to indicate hugepd */
> - return ((hpd_val(hpd) & PD_HUGE) ==  0);
> + return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0);
>  #endif
>  }
>
> -- 
> 1.8.3.1

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-02-17 Thread Laurentiu Tudor 


On 02/17/2017 12:08 PM, Scott Wood wrote:
> On Thu, 2017-02-16 at 09:11 -0600, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor 
>>
>> On 32-bit book-e machines, hugepd_ok() does not take
>> into account null hugepd values, causing this crash at boot:
>
> Why only 32-bit?

I wanted to get this patch out as quick as possible so i didn't had
time to investigate in depth. I just tested on 64-bit that the
kernel boots ok.

>> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
>> b/arch/powerpc/include/asm/nohash/pgtable.h
>> index 0cd8a38..e5805ad 100644
>> --- a/arch/powerpc/include/asm/nohash/pgtable.h
>> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
>> @@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd)
>>  return ((hpd_val(hpd) & 0x4) != 0);
>>   #else
>>  /* We clear the top bit to indicate hugepd */
>> -return ((hpd_val(hpd) & PD_HUGE) ==  0);
>> +return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0);
>>   #endif
>>   }
>>
>
> Any reason why this can't go back to being "hpd_val(hpd) > 0"?  Why was nohash
> changed to begin with?  I don't expect nohash (or at least fsl-book3e) will
> ever have a pagetable that is not native-endian, and "> 0" is consistent with
> what the TLB miss code is doing.

The patch that introduced the brokenness changes "hugepd_t.pd" from 
"signed long" to "unsigned long" so as a consequence "> 0" was replaced
with the bitwise op.

---
Best Regards, Laurentiu

Re: [PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-02-17 Thread Scott Wood 
On Thu, 2017-02-16 at 09:11 -0600, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor 
> 
> On 32-bit book-e machines, hugepd_ok() does not take
> into account null hugepd values, causing this crash at boot:

Why only 32-bit?

> diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
> b/arch/powerpc/include/asm/nohash/pgtable.h
> index 0cd8a38..e5805ad 100644
> --- a/arch/powerpc/include/asm/nohash/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/pgtable.h
> @@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd)
>   return ((hpd_val(hpd) & 0x4) != 0);
>  #else
>   /* We clear the top bit to indicate hugepd */
> - return ((hpd_val(hpd) & PD_HUGE) ==  0);
> + return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0);
>  #endif
>  }
>  

Any reason why this can't go back to being "hpd_val(hpd) > 0"?  Why was nohash
changed to begin with?  I don't expect nohash (or at least fsl-book3e) will
ever have a pagetable that is not native-endian, and "> 0" is consistent with
what the TLB miss code is doing.

Also, the patch that broke this was tagged for stable (which again raises the
question of why an extraneous change was made) so this patch needs to be as
well.

-Scott

[PATCH] powerpc: booke: fix boot crash due to null hugepd

2017-02-16 Thread laurentiu.tudor 
From: Laurentiu Tudor 

On 32-bit book-e machines, hugepd_ok() does not take
into account null hugepd values, causing this crash at boot:

Unable to handle kernel paging request for data at address 0x8000
Faulting instruction address: 0xc00182a8
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=24
CoreNet Generic
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW   
4.10.0-rc8-00016-g69b1f87 #11
task: e505 task.stack: e5058000
NIP: c00182a8 LR: c001829c CTR: 7ffe
REGS: e5059c50 TRAP: 0300   Tainted: GW
(4.10.0-rc8-00016-g69b1f87)
MSR: 00021002 
  CR: 88428e82  XER: 
DEAR: 8000 ESR: 
GPR00: c0107510 e5059d00 e505 8000 bff1 e5059d0c e5059d08 2017
GPR08:     28428e82  c00027d0 
GPR16:   88a28e82 2000 48422e82  88a28e84 dd004000
GPR24: e5059e38   bff1 dd004000 0001 00029002 bff1
NIP [c00182a8] follow_huge_addr+0x38/0xf0
LR [c001829c] follow_huge_addr+0x2c/0xf0
Call Trace:
[e5059d00] [e5059d00] 0xe5059d00 (unreliable)
[e5059d20] [c0107510] follow_page_mask+0x40/0x3c0
[e5059d80] [c0107958] __get_user_pages+0xc8/0x420
[e5059de0] [c010817c] get_user_pages_remote+0x8c/0x230
[e5059e30] [c013f170] copy_strings+0x110/0x3a0
[e5059ea0] [c013f42c] copy_strings_kernel+0x2c/0x50
[e5059ec0] [c0141324] do_execveat_common+0x474/0x620
[e5059f10] [c01414fc] do_execve+0x2c/0x40
[e5059f20] [c0001f68] try_to_run_init_process+0x18/0x60
[e5059f30] [c000289c] kernel_init+0xcc/0x120
[e5059f40] [c000f1e8] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
bfc10018 7c9f2378 90010024 7fc000a6 7c000146 80630020 38a1000c 38c10008
4bfff869 2c03 41c20090 81210008 <8143> 81630004 3860ffea 2f89
---[ end trace 4bf94e15fd9fa824 ]---

This impacts all nxp (ex-freescale) 32-bit booke platforms.

Fixes: 20717e1ff526 ("powerpc/mm: Fix little-endian 4K hugetlb")

Reported-by: Madalin-Cristian Bucur 
Signed-off-by: Laurentiu Tudor 
---
 arch/powerpc/include/asm/nohash/pgtable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/nohash/pgtable.h 
b/arch/powerpc/include/asm/nohash/pgtable.h
index 0cd8a38..e5805ad 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -230,7 +230,7 @@ static inline int hugepd_ok(hugepd_t hpd)
return ((hpd_val(hpd) & 0x4) != 0);
 #else
/* We clear the top bit to indicate hugepd */
-   return ((hpd_val(hpd) & PD_HUGE) ==  0);
+   return (hpd_val(hpd) && (hpd_val(hpd) & PD_HUGE) == 0);
 #endif
 }
 
-- 
1.8.3.1