Re: [PATCH] powerpc/mm: use the correct pointer when setting a 2M pte

[Aneesh Kumar K.V]

Reza Arbab  writes:

> When setting a 2M pte, radix__map_kernel_page() is using the address
>
>   ptep = (pte_t *)pudp;
>
> Fix this conversion to use pmdp instead. Use pmdp_ptep() to do this
> instead of casting the pointer.
>

Reviewed-by: Aneesh Kumar K.V 

> Signed-off-by: Reza Arbab 
> ---
>  arch/powerpc/mm/pgtable-radix.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
> index cfa53cc..34f1a0d 100644
> --- a/arch/powerpc/mm/pgtable-radix.c
> +++ b/arch/powerpc/mm/pgtable-radix.c
> @@ -65,7 +65,7 @@ int radix__map_kernel_page(unsigned long ea, unsigned long 
> pa,
>   if (!pmdp)
>   return -ENOMEM;
>   if (map_page_size == PMD_SIZE) {
> - ptep = (pte_t *)pudp;
> + ptep = pmdp_ptep(pmdp);
>   goto set_the_pte;
>   }
>   ptep = pte_alloc_kernel(pmdp, ea);
> @@ -90,7 +90,7 @@ int radix__map_kernel_page(unsigned long ea, unsigned long 
> pa,
>   }
>   pmdp = pmd_offset(pudp, ea);
>   if (map_page_size == PMD_SIZE) {
> - ptep = (pte_t *)pudp;
> + ptep = pmdp_ptep(pmdp);
>   goto set_the_pte;
>   }
>   if (!pmd_present(*pmdp)) {
> -- 
> 1.8.3.1

[PATCH] powerpc/mm/hash: Properly mask the ESID bits when building proto-VSID

[Aneesh Kumar K.V]

proto-vsid is built using both mmu context id and ESID. We should not have
overlapping bits between those. That will result in us having vsid
collision. With the current code we missed masking the top bits of effective
address. This implies for kernel address we ended up using the top 4 bits
as part of proto-vsid, which is wrong. For the kernel we should have the
below mapping

0xf000 -> 0x7  (19 bits context + 6 bits ESID ).

Without the patch we endup with
0xf000 ->  0xf7 (0x7 | 0xf0)

We didn't observe any issues till now possibly because we never end up
using a context value which could map to the same  VSID as kernel.

Fixes: c60ac5693c4 ("powerpc: Update kernel VSID range")

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/mmu-hash.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index 2e6a823fa502..0735d5a8049f 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -525,6 +525,8 @@ extern void slb_set_size(u16 size);
 #define ESID_BITS  18
 #define ESID_BITS_1T   6
 
+#define ESID_BITS_MASK ((1 << ESID_BITS) - 1)
+#define ESID_BITS_1T_MASK  ((1 << ESID_BITS_1T) - 1)
 /*
  * 256MB segment
  * The proto-VSID space has 2^(CONTEX_BITS + ESID_BITS) - 1 segments
@@ -660,9 +662,9 @@ static inline unsigned long get_vsid(unsigned long context, 
unsigned long ea,
 
if (ssize == MMU_SEGSIZE_256M)
return vsid_scramble((context << ESID_BITS)
-| (ea >> SID_SHIFT), 256M);
+| ((ea >> SID_SHIFT) & ESID_BITS_MASK), 
256M);
return vsid_scramble((context << ESID_BITS_1T)
-| (ea >> SID_SHIFT_1T), 1T);
+| ((ea >> SID_SHIFT_1T) & ESID_BITS_1T_MASK), 1T);
 }
 
 /*
-- 
2.10.2

Re: [next-20170124] Kernel oops(rt6_fill_node) during reboot of LPAR

[David Ahern]

On 1/27/17 5:54 AM, Sachin Sant wrote:
> While rebooting PowerVM LPAR running 4.10.0-rc5-next-20170124
> on a POWER8 box, following kernel oops is displayed.
> 
> This problem was introduced with next-20170123. next-20170120 works.
> Initial analysis points to following patch included with next-20170123
> 
> commit a1a22c12060e4b9c52f45d4b3460f614e00162a2
> net: ipv6: Keep nexthop of multipath route on admin down

Thanks for the report. Fixed by:

https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1f17e2f2c8a8be3430813119fa7b633398f6185b