1. 13 Mar, 2018 33 commits
  2. 05 Mar, 2018 7 commits
    • Christophe Leroy's avatar
      powerpc/8xx: Increase number of slices to 64 · 4bd13772
      Christophe Leroy authored
      On the 8xx, the minimum slice size is the size of the area
      covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
      16K pages mode.
      
      This patch increases the number of slices from 16 to 64 on the 8xx.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      4bd13772
    • Christophe Leroy's avatar
      powerpc/mm/slice: Allow up to 64 low slices · 15472423
      Christophe Leroy authored
      While the implementation of the "slices" address space allows
      a significant amount of high slices, it limits the number of
      low slices to 16 due to the use of a single u64 low_slices_psize
      element in struct mm_context_t
      
      On the 8xx, the minimum slice size is the size of the area
      covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
      16K pages mode. This means we could have at least 64 slices.
      
      In order to override this limitation, this patch switches the
      handling of low_slices_psize to char array as done already for
      high_slices_psize.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      15472423
    • Christophe Leroy's avatar
      powerpc/mm/slice: Fix hugepage allocation at hint address on 8xx · aa0ab02b
      Christophe Leroy authored
      On the 8xx, the page size is set in the PMD entry and applies to
      all pages of the page table pointed by the said PMD entry.
      
      When an app has some regular pages allocated (e.g. see below) and tries
      to mmap() a huge page at a hint address covered by the same PMD entry,
      the kernel accepts the hint allthough the 8xx cannot handle different
      page sizes in the same PMD entry.
      
      10000000-10001000 r-xp 00000000 00:0f 2597 /root/malloc
      10010000-10011000 rwxp 00000000 00:0f 2597 /root/malloc
      
      mmap(0x10080000, 524288, PROT_READ|PROT_WRITE,
           MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0) = 0x10080000
      
      This results the app remaining forever in do_page_fault()/hugetlb_fault()
      and when interrupting that app, we get the following warning:
      
      [162980.035629] WARNING: CPU: 0 PID: 2777 at arch/powerpc/mm/hugetlbpage.c:354 hugetlb_free_pgd_range+0xc8/0x1e4
      [162980.035699] CPU: 0 PID: 2777 Comm: malloc Tainted: G W       4.14.6 #85
      [162980.035744] task: c67e2c00 task.stack: c668e000
      [162980.035783] NIP:  c000fe18 LR: c00e1eec CTR: c00f90c0
      [162980.035830] REGS: c668fc20 TRAP: 0700   Tainted: G W        (4.14.6)
      [162980.035854] MSR:  00029032 <EE,ME,IR,DR,RI>  CR: 24044224 XER: 20000000
      [162980.036003]
      [162980.036003] GPR00: c00e1eec c668fcd0 c67e2c00 00000010 c6869410 10080000 00000000 77fb4000
      [162980.036003] GPR08: ffff0001 0683c001 00000000 ffffff80 44028228 10018a34 00004008 418004fc
      [162980.036003] GPR16: c668e000 00040100 c668e000 c06c0000 c668fe78 c668e000 c6835ba0 c668fd48
      [162980.036003] GPR24: 00000000 73ffffff 74000000 00000001 77fb4000 100fffff 10100000 10100000
      [162980.036743] NIP [c000fe18] hugetlb_free_pgd_range+0xc8/0x1e4
      [162980.036839] LR [c00e1eec] free_pgtables+0x12c/0x150
      [162980.036861] Call Trace:
      [162980.036939] [c668fcd0] [c00f0774] unlink_anon_vmas+0x1c4/0x214 (unreliable)
      [162980.037040] [c668fd10] [c00e1eec] free_pgtables+0x12c/0x150
      [162980.037118] [c668fd40] [c00eabac] exit_mmap+0xe8/0x1b4
      [162980.037210] [c668fda0] [c0019710] mmput.part.9+0x20/0xd8
      [162980.037301] [c668fdb0] [c001ecb0] do_exit+0x1f0/0x93c
      [162980.037386] [c668fe00] [c001f478] do_group_exit+0x40/0xcc
      [162980.037479] [c668fe10] [c002a76c] get_signal+0x47c/0x614
      [162980.037570] [c668fe70] [c0007840] do_signal+0x54/0x244
      [162980.037654] [c668ff30] [c0007ae8] do_notify_resume+0x34/0x88
      [162980.037744] [c668ff40] [c000dae8] do_user_signal+0x74/0xc4
      [162980.037781] Instruction dump:
      [162980.037821] 7fdff378 81370000 54a3463a 80890020 7d24182e 7c841a14 712a0004 4082ff94
      [162980.038014] 2f890000 419e0010 712a0ff0 408200e0 <0fe00000> 54a9000a 7f984840 419d0094
      [162980.038216] ---[ end trace c0ceeca8e7a5800a ]---
      [162980.038754] BUG: non-zero nr_ptes on freeing mm: 1
      [162985.363322] BUG: non-zero nr_ptes on freeing mm: -1
      
      In order to fix this, this patch uses the address space "slices"
      implemented for BOOK3S/64 and enhanced to support PPC32 by the
      preceding patch.
      
      This patch modifies the context.id on the 8xx to be in the range
      [1:16] instead of [0:15] in order to identify context.id == 0 as
      not initialised contexts as done on BOOK3S
      
      This patch activates CONFIG_PPC_MM_SLICES when CONFIG_HUGETLB_PAGE is
      selected for the 8xx
      
      Alltough we could in theory have as many slices as PMD entries, the
      current slices implementation limits the number of low slices to 16.
      This limitation is not preventing us to fix the initial issue allthough
      it is suboptimal. It will be cured in a subsequent patch.
      
      Fixes: 4b914286 ("powerpc/8xx: Implement support of hugepages")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      aa0ab02b
    • Christophe Leroy's avatar
      powerpc/mm/slice: Enhance for supporting PPC32 · db3a528d
      Christophe Leroy authored
      In preparation for the following patch which will fix an issue on
      the 8xx by re-using the 'slices', this patch enhances the
      'slices' implementation to support 32 bits CPUs.
      
      On PPC32, the address space is limited to 4Gbytes, hence only the low
      slices will be used.
      
      The high slices use bitmaps. As bitmap functions are not prepared to
      handle bitmaps of size 0, this patch ensures that bitmap functions
      are called only when SLICE_NUM_HIGH is not nul.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      db3a528d
    • Christophe Leroy's avatar
      powerpc/mm/slice: create header files dedicated to slices · a3286f05
      Christophe Leroy authored
      In preparation for the following patch which will enhance 'slices'
      for supporting PPC32 in order to fix an issue on hugepages on 8xx,
      this patch takes out of page*.h all bits related to 'slices' and put
      them into newly created slice.h header files.
      While common parts go into asm/slice.h, subarch specific
      parts go into respective books3s/64/slice.c and nohash/64/slice.c
      'slices'
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      a3286f05
    • Christophe Leroy's avatar
      powerpc/mm/slice: Remove intermediate bitmap copy · 326691ad
      Christophe Leroy authored
      bitmap_or() and bitmap_andnot() can work properly with dst identical
      to src1 or src2. There is no need of an intermediate result bitmap
      that is copied back to dst in a second step.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Reviewed-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      326691ad
    • Segher Boessenkool's avatar
      powerpc: Keep const vars out of writable .sdata · 51d42f0f
      Segher Boessenkool authored
      Newer gcc will support "-mno-readonly-in-sdata"[1], which makes sure that
      the optimization on PPC32 for variables getting moved into the .sdata
      section will not apply to const variables (which must be in .rodata).
      
      This was originally noticed in mm/rodata_test.c when rodata_test_data
      was not static:
      
      c0695034 g     O .data	00000004 rodata_test_data
      
      After this patch with an updated compiler, this is correctly in .rodata.
      
      [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82411Reported-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarSegher Boessenkool <segher@kernel.crashing.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      51d42f0f