1. 13 Oct, 2018 4 commits
    • Christophe Leroy's avatar
      powerpc/process: Fix interleaved output in show_user_instructions() · fb2d9505
      Christophe Leroy authored
      When two processes crash at the same time, we sometimes encounter
      interleaving in the middle of a line:
      
        init[1]: segfault (11) at 0 nip 0 lr 0 code 1
        init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
        init[74]: segfault (11) at 10a74 nip 1000c198 lr 100078c8 code 1 in sh[10000000+14000]
        XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
        init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
        init[74]: code: 90010024 bf61000c 91490a7c 3fa01002 3be00000 7d3e4b78 3bbd0c20 3b600000
        init[74]: code: 3b9d0040 7c7fe02e 2f830000 419e0028 <89230000> 2f890000 41be001c 4b7f6e79
      
      This patch fixes it by preparing complete lines in a buffer and
      printing it at once.
      
      Fixes: 88b0fe17 ("powerpc: Add show_user_instructions()")
      Reviewed-by: default avatarMurilo Opsfelder Araujo <muriloo@linux.ibm.com>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      [mpe: Use seq_buf_printf() not seq_buf_puts() which doesn't NULL terminate]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      fb2d9505
    • Christophe Leroy's avatar
      powerpc/process: Add missing include of stacktrace.h · c9386bfd
      Christophe Leroy authored
      As spotted by sparse:
      
        arch/powerpc/kernel/process.c:1302:6: warning: symbol 'show_user_instructions' was not declared. Should it be static?
      
      Fixes: 88b0fe17 ("powerpc: Add show_user_instructions()")
      Reviewed-by: default avatarMurilo Opsfelder Araujo <muriloo@linux.ibm.com>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      [mpe: Split out of larger patch]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      c9386bfd
    • Christophe Leroy's avatar
      powerpc/process: Fix sparse address space warnings · 3b35bd48
      Christophe Leroy authored
      This patch fixes the following warnings, which are leftovers
      from when __get_user() was replaced by probe_kernel_address().
      
      arch/powerpc/kernel/process.c:1287:22: warning: incorrect type in argument 2 (different address spaces)
      arch/powerpc/kernel/process.c:1287:22:    expected void const *src
      arch/powerpc/kernel/process.c:1287:22:    got unsigned int [noderef] <asn:1>*<noident>
      arch/powerpc/kernel/process.c:1319:21: warning: incorrect type in argument 2 (different address spaces)
      arch/powerpc/kernel/process.c:1319:21:    expected void const *src
      arch/powerpc/kernel/process.c:1319:21:    got unsigned int [noderef] <asn:1>*<noident>
      
      Fixes: 7b051f66 ("powerpc: Use probe_kernel_address in show_instructions")
      Reviewed-by: default avatarMurilo Opsfelder Araujo <muriloo@linux.ibm.com>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      [mpe: Split out of larger patch]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      3b35bd48
    • Christophe Leroy's avatar
      powerpc/64: properly initialise the stackprotector canary on SMP. · 7241d26e
      Christophe Leroy authored
      commit 06ec27ae ("powerpc/64: add stack protector support")
      doesn't initialise the stack canary on SMP secondary CPU's paca,
      leading to the following false positive report from the
      stack protector.
      
      smp: Bringing up secondary CPUs ...
      Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __schedule+0x978/0xa80
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.0-rc7-next-20181010-autotest-autotest #1
      Call Trace:
      [c000001fed5b3bf0] [c000000000a0ef3c] dump_stack+0xb0/0xf4 (unreliable)
      [c000001fed5b3c30] [c0000000000f9d68] panic+0x140/0x308
      [c000001fed5b3cc0] [c0000000000f9844] __stack_chk_fail+0x24/0x30
      [c000001fed5b3d20] [c000000000a2c3a8] __schedule+0x978/0xa80
      [c000001fed5b3e00] [c000000000a2c9b4] schedule_idle+0x34/0x60
      [c000001fed5b3e30] [c00000000013d344] do_idle+0x224/0x3d0
      [c000001fed5b3ec0] [c00000000013d6e0] cpu_startup_entry+0x30/0x50
      [c000001fed5b3ef0] [c000000000047f34] start_secondary+0x4d4/0x520
      [c000001fed5b3f90] [c00000000000b370] start_secondary_prolog+0x10/0x14
      
      This patch properly initialises the stack_canary of the secondary
      idle tasks.
      Reported-by: default avatarAbdul Haleem <abdhalee@linux.vnet.ibm.com>
      Fixes: 06ec27ae ("powerpc/64: add stack protector support")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7241d26e
  2. 09 Oct, 2018 1 commit
    • Michael Ellerman's avatar
      Merge branch 'fixes' into next · 9b7e4d60
      Michael Ellerman authored
      Merge our fixes branch. It has a few important fixes that are needed for
      futher testing and also some commits that will conflict with content in
      next.
      9b7e4d60
  3. 08 Oct, 2018 7 commits
  4. 05 Oct, 2018 2 commits
    • Srikar Dronamraju's avatar
      powerpc/numa: Skip onlining a offline node in kdump path · ac1788cc
      Srikar Dronamraju authored
      With commit 2ea62630 ("powerpc/topology: Get topology for shared
      processors at boot"), kdump kernel on shared LPAR may crash.
      
      The necessary conditions are
      - Shared LPAR with at least 2 nodes having memory and CPUs.
      - Memory requirement for kdump kernel must be met by the first N-1
        nodes where there are at least N nodes with memory and CPUs.
      
      Example numactl of such a machine.
        $ numactl -H
        available: 5 nodes (0,2,5-7)
        node 0 cpus:
        node 0 size: 0 MB
        node 0 free: 0 MB
        node 2 cpus:
        node 2 size: 255 MB
        node 2 free: 189 MB
        node 5 cpus: 24 25 26 27 28 29 30 31
        node 5 size: 4095 MB
        node 5 free: 4024 MB
        node 6 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
        node 6 size: 6353 MB
        node 6 free: 5998 MB
        node 7 cpus: 8 9 10 11 12 13 14 15 32 33 34 35 36 37 38 39
        node 7 size: 7640 MB
        node 7 free: 7164 MB
        node distances:
        node   0   2   5   6   7
          0:  10  40  40  40  40
          2:  40  10  40  40  40
          5:  40  40  10  40  40
          6:  40  40  40  10  20
          7:  40  40  40  20  10
      
      Steps to reproduce.
      1. Load / start kdump service.
      2. Trigger a kdump (for example : echo c > /proc/sysrq-trigger)
      
      When booting a kdump kernel with 2048M:
      
        kexec: Starting switchover sequence.
        I'm in purgatory
        Using 1TB segments
        hash-mmu: Initializing hash mmu with SLB
        Linux version 4.19.0-rc5-master+ (srikar@linux-xxu6) (gcc version 4.8.5 (SUSE Linux)) #1 SMP Thu Sep 27 19:45:00 IST 2018
        Found initrd at 0xc000000009e70000:0xc00000000ae554b4
        Using pSeries machine description
        -----------------------------------------------------
        ppc64_pft_size    = 0x1e
        phys_mem_size     = 0x88000000
        dcache_bsize      = 0x80
        icache_bsize      = 0x80
        cpu_features      = 0x000000ff8f5d91a7
          possible        = 0x0000fbffcf5fb1a7
          always          = 0x0000006f8b5c91a1
        cpu_user_features = 0xdc0065c2 0xef000000
        mmu_features      = 0x7c006001
        firmware_features = 0x00000007c45bfc57
        htab_hash_mask    = 0x7fffff
        physical_start    = 0x8000000
        -----------------------------------------------------
        numa:   NODE_DATA [mem 0x87d5e300-0x87d67fff]
        numa:     NODE_DATA(0) on node 6
        numa:   NODE_DATA [mem 0x87d54600-0x87d5e2ff]
        Top of RAM: 0x88000000, Total RAM: 0x88000000
        Memory hole size: 0MB
        Zone ranges:
          DMA      [mem 0x0000000000000000-0x0000000087ffffff]
          DMA32    empty
          Normal   empty
        Movable zone start for each node
        Early memory node ranges
          node   6: [mem 0x0000000000000000-0x0000000087ffffff]
        Could not find start_pfn for node 0
        Initmem setup node 0 [mem 0x0000000000000000-0x0000000000000000]
        On node 0 totalpages: 0
        Initmem setup node 6 [mem 0x0000000000000000-0x0000000087ffffff]
        On node 6 totalpages: 34816
      
        Unable to handle kernel paging request for data at address 0x00000060
        Faulting instruction address: 0xc000000008703a54
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in:
        CPU: 11 PID: 1 Comm: swapper/11 Not tainted 4.19.0-rc5-master+ #1
        NIP:  c000000008703a54 LR: c000000008703a38 CTR: 0000000000000000
        REGS: c00000000b673440 TRAP: 0380   Not tainted  (4.19.0-rc5-master+)
        MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 24022022  XER: 20000002
        CFAR: c0000000086fc238 IRQMASK: 0
        GPR00: c000000008703a38 c00000000b6736c0 c000000009281900 0000000000000000
        GPR04: 0000000000000000 0000000000000000 fffffffffffff001 c00000000b660080
        GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000220
        GPR12: 0000000000002200 c000000009e51400 0000000000000000 0000000000000008
        GPR16: 0000000000000000 c000000008c152e8 c000000008c152a8 0000000000000000
        GPR20: c000000009422fd8 c000000009412fd8 c000000009426040 0000000000000008
        GPR24: 0000000000000000 0000000000000000 c000000009168bc8 c000000009168c78
        GPR28: c00000000b126410 0000000000000000 c00000000916a0b8 c00000000b126400
        NIP [c000000008703a54] bus_add_device+0x84/0x1e0
        LR [c000000008703a38] bus_add_device+0x68/0x1e0
        Call Trace:
        [c00000000b6736c0] [c000000008703a38] bus_add_device+0x68/0x1e0 (unreliable)
        [c00000000b673740] [c000000008700194] device_add+0x454/0x7c0
        [c00000000b673800] [c00000000872e660] __register_one_node+0xb0/0x240
        [c00000000b673860] [c00000000839a6bc] __try_online_node+0x12c/0x180
        [c00000000b673900] [c00000000839b978] try_online_node+0x58/0x90
        [c00000000b673930] [c0000000080846d8] find_and_online_cpu_nid+0x158/0x190
        [c00000000b673a10] [c0000000080848a0] numa_update_cpu_topology+0x190/0x580
        [c00000000b673c00] [c000000008d3f2e4] smp_cpus_done+0x94/0x108
        [c00000000b673c70] [c000000008d5c00c] smp_init+0x174/0x19c
        [c00000000b673d00] [c000000008d346b8] kernel_init_freeable+0x1e0/0x450
        [c00000000b673dc0] [c0000000080102e8] kernel_init+0x28/0x160
        [c00000000b673e30] [c00000000800b65c] ret_from_kernel_thread+0x5c/0x80
        Instruction dump:
        60000000 60000000 e89e0020 7fe3fb78 4bff87d5 60000000 7c7d1b79 4082008c
        e8bf0050 e93e0098 3b9f0010 2fa50000 <e8690060> 38630018 419e0114 7f84e378
        ---[ end trace 593577668c2daa65 ]---
      
      However a regular kernel with 4096M (2048 gets reserved for crash
      kernel) boots properly.
      
      Unlike regular kernels, which mark all available nodes as online,
      kdump kernel only marks just enough nodes as online and marks the rest
      as offline at boot. However kdump kernel boots with all available
      CPUs. With Commit 2ea62630 ("powerpc/topology: Get topology for
      shared processors at boot"), all CPUs are onlined on their respective
      nodes at boot time. try_online_node() tries to online the offline
      nodes but fails as all needed subsystems are not yet initialized.
      
      As part of fix, detect and skip early onlining of a offline node.
      
      Fixes: 2ea62630 ("powerpc/topology: Get topology for shared processors at boot")
      Reported-by: default avatarPavithra Prakash <pavrampu@in.ibm.com>
      Signed-off-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Tested-by: default avatarHari Bathini <hbathini@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ac1788cc
    • Michael Ellerman's avatar
      powerpc: Don't print kernel instructions in show_user_instructions() · a932ed3b
      Michael Ellerman authored
      Recently we implemented show_user_instructions() which dumps the code
      around the NIP when a user space process dies with an unhandled
      signal. This was modelled on the x86 code, and we even went so far as
      to implement the exact same bug, namely that if the user process
      crashed with its NIP pointing into the kernel we will dump kernel text
      to dmesg. eg:
      
        bad-bctr[2996]: segfault (11) at c000000000010000 nip c000000000010000 lr 12d0b0894 code 1
        bad-bctr[2996]: code: fbe10068 7cbe2b78 7c7f1b78 fb610048 38a10028 38810020 fb810050 7f8802a6
        bad-bctr[2996]: code: 3860001c f8010080 48242371 60000000 <7c7b1b79> 4082002c e8010080 eb610048
      
      This was discovered on x86 by Jann Horn and fixed in commit
      342db04a ("x86/dumpstack: Don't dump kernel memory based on usermode RIP").
      
      Fix it by checking the adjusted NIP value (pc) and number of
      instructions against USER_DS, and bail if we fail the check, eg:
      
        bad-bctr[2969]: segfault (11) at c000000000010000 nip c000000000010000 lr 107930894 code 1
        bad-bctr[2969]: Bad NIP, not dumping instructions.
      
      Fixes: 88b0fe17 ("powerpc: Add show_user_instructions()")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      a932ed3b
  5. 04 Oct, 2018 9 commits
    • Nicholas Piggin's avatar
      powerpc/64s/radix: Explicitly flush ERAT with local LPID invalidation · 053c5a75
      Nicholas Piggin authored
      Local radix TLB flush operations that operate on congruence classes
      have explicit ERAT flushes for POWER9. The process scoped LPID flush
      did not have a flush, so add it.
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      053c5a75
    • Nicholas Piggin's avatar
      powerpc/64s/hash: Do not use PPC_INVALIDATE_ERAT on CPUs before POWER9 · bc276ecb
      Nicholas Piggin authored
      PPC_INVALIDATE_ERAT is slbia IH=7 which is a new variant introduced
      with POWER9, and the result is undefined on earlier CPUs.
      
      Commits 7b9f71f9 ("powerpc/64s: POWER9 machine check handler") and
      d4748276 ("powerpc/64s: Improve local TLB flush for boot and MCE on
      POWER9") caused POWER7/8 code to use this instruction. Remove it. An
      ERAT flush can be made by invalidatig the SLB, but before POWER9 that
      requires a flush and rebolt.
      
      Fixes: 7b9f71f9 ("powerpc/64s: POWER9 machine check handler")
      Fixes: d4748276 ("powerpc/64s: Improve local TLB flush for boot and MCE on POWER9")
      Cc: stable@vger.kernel.org # v4.11+
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      bc276ecb
    • Anton Blanchard's avatar
      powerpc/time: Add set_state_oneshot_stopped decrementer callback · 81759360
      Anton Blanchard authored
      If CONFIG_PPC_WATCHDOG is enabled we always cap the decrementer to
      0x7fffffff:
      
             if (IS_ENABLED(CONFIG_PPC_WATCHDOG))
                      set_dec(0x7fffffff);
              else
                      set_dec(decrementer_max);
      
      If there are no future events, we don't reprogram the decrementer
      after this and we end up with 0x7fffffff even on a large decrementer
      capable system.
      
      As suggested by Nick, add a set_state_oneshot_stopped callback
      so we program the decrementer with decrementer_max if there are
      no future events.
      Signed-off-by: default avatarAnton Blanchard <anton@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      81759360
    • Anton Blanchard's avatar
      powerpc/time: Use clockevents_register_device(), fixing an issue with large decrementer · 8b78fdb0
      Anton Blanchard authored
      We currently cap the decrementer clockevent at 4 seconds, even on systems
      with large decrementer support. Fix this by converting the code to use
      clockevents_register_device() which calculates the upper bound based on
      the max_delta passed in.
      Signed-off-by: default avatarAnton Blanchard <anton@ozlabs.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      8b78fdb0
    • Mark Hairgrove's avatar
      powerpc/powernv/npu: Remove atsd_threshold debugfs setting · f86ad3e0
      Mark Hairgrove authored
      This threshold is no longer used now that all invalidates issue a single
      ATSD to each active NPU.
      Signed-off-by: default avatarMark Hairgrove <mhairgrove@nvidia.com>
      Reviewed-by: default avatarAlistair Popple <alistair@popple.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f86ad3e0
    • Mark Hairgrove's avatar
      powerpc/powernv/npu: Use size-based ATSD invalidates · 3689c37d
      Mark Hairgrove authored
      Prior to this change only two types of ATSDs were issued to the NPU:
      invalidates targeting a single page and invalidates targeting the whole
      address space. The crossover point happened at the configurable
      atsd_threshold which defaulted to 2M. Invalidates that size or smaller
      would issue per-page invalidates for the whole range.
      
      The NPU supports more invalidation sizes however: 64K, 2M, 1G, and all.
      These invalidates target addresses aligned to their size. 2M is a common
      invalidation size for GPU-enabled applications because that is a GPU
      page size, so reducing the number of invalidates by 32x in that case is a
      clear improvement.
      
      ATSD latency is high in general so now we always issue a single invalidate
      rather than multiple. This will over-invalidate in some cases, but for any
      invalidation size over 2M it matches or improves the prior behavior.
      There's also an improvement for single-page invalidates since the prior
      version issued two invalidates for that case instead of one.
      
      With this change all issued ATSDs now perform a flush, so the flush
      parameter has been removed from all the helpers.
      
      To show the benefit here are some performance numbers from a
      microbenchmark which creates a 1G allocation then uses mprotect with
      PROT_NONE to trigger invalidates in strides across the allocation.
      
      One NPU (1 GPU):
      
               mprotect rate (GB/s)
      Stride   Before      After      Speedup
      64K         5.3        5.6           5%
      1M         39.3       57.4          46%
      2M         49.7       82.6          66%
      4M        286.6      285.7           0%
      
      Two NPUs (6 GPUs):
      
               mprotect rate (GB/s)
      Stride   Before      After      Speedup
      64K         6.5        7.4          13%
      1M         33.4       67.9         103%
      2M         38.7       93.1         141%
      4M        356.7      354.6          -1%
      
      Anything over 2M is roughly the same as before since both cases issue a
      single ATSD.
      Signed-off-by: default avatarMark Hairgrove <mhairgrove@nvidia.com>
      Reviewed-By: default avatarAlistair Popple <alistair@popple.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      3689c37d
    • Mark Hairgrove's avatar
      powerpc/powernv/npu: Reduce eieio usage when issuing ATSD invalidates · 7ead15a1
      Mark Hairgrove authored
      There are two types of ATSDs issued to the NPU: invalidates targeting a
      specific virtual address and invalidates targeting the whole address
      space. In both cases prior to this change, the sequence was:
      
          for each NPU
              - Write the target address to the XTS_ATSD_AVA register
              - EIEIO
              - Write the launch value to issue the ATSD
      
      First, a target address is not required when invalidating the whole
      address space, so that write and the EIEIO have been removed. The AP
      (size) field in the launch is not needed either.
      
      Second, for per-address invalidates the above sequence is inefficient in
      the common case of multiple NPUs because an EIEIO is issued per NPU. This
      unnecessarily forces the launches of later ATSDs to be ordered with the
      launches of earlier ones. The new sequence only issues a single EIEIO:
      
          for each NPU
              - Write the target address to the XTS_ATSD_AVA register
          EIEIO
          for each NPU
              - Write the launch value to issue the ATSD
      
      Performance results were gathered using a microbenchmark which creates a
      1G allocation then uses mprotect with PROT_NONE to trigger invalidates in
      strides across the allocation.
      
      With only a single NPU active (one GPU) the difference is in the noise for
      both types of invalidates (+/-1%).
      
      With two NPUs active (on a 6-GPU system) the effect is more noticeable:
      
               mprotect rate (GB/s)
      Stride   Before      After      Speedup
      64K         5.9        6.5          10%
      1M         31.2       33.4           7%
      2M         36.3       38.7           7%
      4M        322.6      356.7          11%
      Signed-off-by: default avatarMark Hairgrove <mhairgrove@nvidia.com>
      Reviewed-by: default avatarAlistair Popple <alistair@popple.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7ead15a1
    • Masahiro Yamada's avatar
      powerpc: remove leftover code of old GCC version checks · bad96de8
      Masahiro Yamada authored
      Clean up the leftover of commit f2910f0e ("powerpc: remove old
      GCC version checks").
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      bad96de8
    • Daniel Axtens's avatar
      powerpc/nohash: fix undefined behaviour when testing page size support · f5e28480
      Daniel Axtens authored
      When enumerating page size definitions to check hardware support,
      we construct a constant which is (1U << (def->shift - 10)).
      
      However, the array of page size definitions is only initalised for
      various MMU_PAGE_* constants, so it contains a number of 0-initialised
      elements with def->shift == 0. This means we end up shifting by a
      very large number, which gives the following UBSan splat:
      
      ================================================================================
      UBSAN: Undefined behaviour in /home/dja/dev/linux/linux/arch/powerpc/mm/tlb_nohash.c:506:21
      shift exponent 4294967286 is too large for 32-bit type 'unsigned int'
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc3-00045-ga604f927b012-dirty #6
      Call Trace:
      [c00000000101bc20] [c000000000a13d54] .dump_stack+0xa8/0xec (unreliable)
      [c00000000101bcb0] [c0000000004f20a8] .ubsan_epilogue+0x18/0x64
      [c00000000101bd30] [c0000000004f2b10] .__ubsan_handle_shift_out_of_bounds+0x110/0x1a4
      [c00000000101be20] [c000000000d21760] .early_init_mmu+0x1b4/0x5a0
      [c00000000101bf10] [c000000000d1ba28] .early_setup+0x100/0x130
      [c00000000101bf90] [c000000000000528] start_here_multiplatform+0x68/0x80
      ================================================================================
      
      Fix this by first checking if the element exists (shift != 0) before
      constructing the constant.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f5e28480
  6. 03 Oct, 2018 17 commits
    • Christophe Leroy's avatar
      powerpc: Wire up memtest · d90fe2ac
      Christophe Leroy authored
      Add call to early_memtest() so that kernel compiled with
      CONFIG_MEMTEST really perform memtest at startup when requested
      via 'memtest' boot parameter.
      Tested-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      d90fe2ac
    • Christophe Leroy's avatar
      powerpc/mm: Don't report hugepage tables as memory leaks when using kmemleak · 803d690e
      Christophe Leroy authored
      When a process allocates a hugepage, the following leak is
      reported by kmemleak. This is a false positive which is
      due to the pointer to the table being stored in the PGD
      as physical memory address and not virtual memory pointer.
      
      unreferenced object 0xc30f8200 (size 512):
        comm "mmap", pid 374, jiffies 4872494 (age 627.630s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<e32b68da>] huge_pte_alloc+0xdc/0x1f8
          [<9e0df1e1>] hugetlb_fault+0x560/0x8f8
          [<7938ec6c>] follow_hugetlb_page+0x14c/0x44c
          [<afbdb405>] __get_user_pages+0x1c4/0x3dc
          [<b8fd7cd9>] __mm_populate+0xac/0x140
          [<3215421e>] vm_mmap_pgoff+0xb4/0xb8
          [<c148db69>] ksys_mmap_pgoff+0xcc/0x1fc
          [<4fcd760f>] ret_from_syscall+0x0/0x38
      
      See commit a984506c ("powerpc/mm: Don't report PUDs as
      memory leaks when using kmemleak") for detailed explanation.
      
      To fix that, this patch tells kmemleak to ignore the allocated
      hugepage table.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      803d690e
    • Michael Neuling's avatar
      powerpc/tm: Reformat comments · 306b1c06
      Michael Neuling authored
      The comments in this file don't conform to the coding style so take
      them to "Comment Formatting Re-Education Camp".
      Suggested-by: default avatarMichael "Camp Drill Sergeant" Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      [mpe: Reflow some comments and add full stops, fix spelling of Sergeant.]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      306b1c06
    • Petr Vorel's avatar
      powerpc/config: Enable CONFIG_PRINTK_TIME · 5bd9b444
      Petr Vorel authored
      for 64bit configs which use for CONFIG_LOG_BUF_SHIFT the same
      or higher value than the default (currently 17).
      Signed-off-by: default avatarPetr Vorel <pvorel@suse.cz>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      5bd9b444
    • YueHaibing's avatar
      powerpc: Remove duplicated include from pci_32.c · 01b9870e
      YueHaibing authored
      Remove duplicated include.
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      01b9870e
    • Michal Suchanek's avatar
      powerpc/64s: consolidate MCE counter increment. · 8a03e81c
      Michal Suchanek authored
      The code in machine_check_exception excludes 64s hvmode when
      incrementing the MCE counter only to call opal_machine_check to
      increment it specifically for this case.
      
      Remove the exclusion and special case.
      
      Fixes: a43c1590 ("powerpc/pseries: Flush SLB contents on SLB MCE
      		errors.")
      Signed-off-by: default avatarMichal Suchanek <msuchanek@suse.de>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      8a03e81c
    • Breno Leitao's avatar
      powerpc/tm: Print 64-bits MSR · 51303113
      Breno Leitao authored
      On a kernel TM Bad thing program exception, the Machine State Register
      (MSR) is not being properly displayed. The exception code dumps a 32-bits
      value but MSR is a 64 bits register for all platforms that have HTM
      enabled.
      
      This patch dumps the MSR value as a 64-bits value instead of 32 bits. In
      order to do so, the 'reason' variable could not be used, since it trimmed
      MSR to 32-bits (int).
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      51303113
    • Breno Leitao's avatar
      powerpc/tm: Remove msr_tm_active() · 5c784c84
      Breno Leitao authored
      Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
      CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
      returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
      
      This function is not necessary, since MSR_TM_ACTIVE() just do the same and
      could be used, removing the dualism and simplifying the code.
      
      This patchset remove every instance of msr_tm_active() and replaced it
      by MSR_TM_ACTIVE().
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      5c784c84
    • Breno Leitao's avatar
      powerpc/powernv: Mark function as __noreturn · 62dea077
      Breno Leitao authored
      There is a mismatch between function pnv_platform_error_reboot() definition
      and declaration regarding function modifiers. In the declaration part, it
      contains the function attribute __noreturn, while function definition
      itself lacks it.
      
      This was reported by sparse tool as an error:
      
        arch/powerpc/platforms/powernv/opal.c:538:6: error: symbol 'pnv_platform_error_reboot' redeclared with different type (originally declared at arch/powerpc/platforms/powernv/powernv.h:11) - different modifiers
      
      I checked and the function is already being considered as being 'noreturn'
      by the compiler, thus, I understand this patch does not change any code
      being generated.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      62dea077
    • Breno Leitao's avatar
      selftests/powerpc: New PTRACE_SYSEMU test · fc35ef12
      Breno Leitao authored
      This patch adds a new test for the new PTRACE_SYSEMU ptrace request.
      
      This test also relies on PTRACE_GETREGS and PTRACE_SETREGS requests to
      run properly, since the trace instruction (gettid() syscall) is being
      modified at run-time (by PTRACE_SETREGS) and re-executed three times.
      PTRACE_GETREGS is being used to check that the registers are still
      sane.
      
      This test basically creates a child process that executes syscalls
      and the parent process check if it is being traced appropriately.  The
      parent process guarantees that the SYSCALLs are being traced, with
      PTRACE_SYSEMU, and ptrace stops the child application before a syscall is
      executed. The way the tests validates it, is by guaranteeing that the
      system calls arguments, as argv[0] (r3) which is the same register that
      will have the syscall return value on powerpc, are not being corrupted on
      PTRACE_SYSEMU with a return value, i.e, it continues to have the current
      arguments instead, meaning that the registers where not clobbered.
      
      This test is basically the same test for x86 located at
      tools/testing/selftests/x86/ptrace_syscall.c, limited to test PTRACE_SYSEMU
      request, and ported to PowerPC.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      fc35ef12
    • Breno Leitao's avatar
      powerpc/ptrace: Add support for PTRACE_SYSEMU · 5521eb4b
      Breno Leitao authored
      This is a patch that adds support for PTRACE_SYSEMU ptrace request in
      PowerPC architecture.
      
      When ptrace(PTRACE_SYSEMU, ...) request is called, it will be handled by
      the arch independent function ptrace_resume(), which will tag the task with
      the TIF_SYSCALL_EMU flag. This flag needs to be handled from a platform
      dependent point of view, which is what this patch does.
      
      This patch adds this task's flag as part of the _TIF_SYSCALL_DOTRACE, which
      is the MACRO that is used to trace syscalls at entrance/exit.
      
      Since TIF_SYSCALL_EMU is now part of _TIF_SYSCALL_DOTRACE, if the task has
      _TIF_SYSCALL_DOTRACE set, it will hit do_syscall_trace_enter() at syscall
      entrance and do_syscall_trace_leave() at syscall leave.
      do_syscall_trace_enter() needs to handle the TIF_SYSCALL_EMU flag properly,
      which will interrupt the syscall executing if TIF_SYSCALL_EMU is set. The
      output values should not be changed, i.e. the return value (r3) should
      contain the original syscall argument on exit.
      
      With this flag set, the syscall is not executed fundamentally, because
      do_syscall_trace_enter() is returning -1 which is bigger than NR_syscall,
      thus, skipping the syscall execution and exiting userspace.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      5521eb4b
    • Breno Leitao's avatar
      powerpc: Redefine TIF_32BITS thread flag · 16d7c69c
      Breno Leitao authored
      Moving TIF_32BIT to use bit 20 instead of 4 in the task flag field.
      
      This change is making room for an upcoming new task macro
      (_TIF_SYSCALL_EMU) which is preferred to set a bit in the lower 16-bits
      part of the word.
      
      This upcoming flag macro will take part in a composed macro
      (_TIF_SYSCALL_DOTRACE) which will contain other flags as well, and it is
      preferred that the whole _TIF_SYSCALL_DOTRACE macro only sets the lower 16
      bits of a word, so, it could be handled using immediate operations (as load
      immediate, add immediate, ...) where the immediate operand (SI) is limited
      to 16-bits.
      
      Another possible solution would be using the LOAD_REG_IMMEDIATE() macro
      to load a full 64-bits word immediate, but it takes 5 operations instead of
      one.
      
      Having TIF_32BITS being redefined to use an upper bit is not a problem
      since there is only one place in the assembly code where TIF_32BIT is being
      used, and it could be replaced with an operation with right shift (addis),
      since it is used alone, i.e. not being part of a composed macro, which has
      different bits set, and would require LOAD_REG_IMMEDIATE().
      
      Tested on a 64 bits Big Endian machine running a 32 bits task.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      16d7c69c
    • Christophe Leroy's avatar
      powerpc/64: add stack protector support · 06ec27ae
      Christophe Leroy authored
      On PPC64, as register r13 points to the paca_struct at all time,
      this patch adds a copy of the canary there, which is copied at
      task_switch.
      That new canary is then used by using the following GCC options:
      -mstack-protector-guard=tls
      -mstack-protector-guard-reg=r13
      -mstack-protector-guard-offset=offsetof(struct paca_struct, canary))
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      06ec27ae
    • Christophe Leroy's avatar
      powerpc/32: add stack protector support · c3ff2a51
      Christophe Leroy authored
      This functionality was tentatively added in the past
      (commit 6533b7c1 ("powerpc: Initial stack protector
      (-fstack-protector) support")) but had to be reverted
      (commit f2574030 ("powerpc: Revert the initial stack
      protector support") because of GCC implementing it differently
      whether it had been built with libc support or not.
      
      Now, GCC offers the possibility to manually set the
      stack-protector mode (global or tls) regardless of libc support.
      
      This time, the patch selects HAVE_STACKPROTECTOR only if
      -mstack-protector-guard=tls is supported by GCC.
      
      On PPC32, as register r2 points to current task_struct at
      all time, the stack_canary located inside task_struct can be
      used directly by using the following GCC options:
      -mstack-protector-guard=tls
      -mstack-protector-guard-reg=r2
      -mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary))
      
      The protector is disabled for prom_init and bootx_init as
      it is too early to handle it properly.
      
       $ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT
      [  134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64
      [  134.943666]
      [  134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835
      [  134.963380] Call Trace:
      [  134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable)
      [  134.971775] [c6615dc0] [c001f654] panic+0x0/0x260
      [  134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64
      [  134.982769] [c6615e00] [ffffffff] 0xffffffff
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      c3ff2a51
    • zhong jiang's avatar
      powerpc/xive: Move a dereference below a NULL test · cd5ff945
      zhong jiang authored
      Move the dereference of xc below the NULL test.
      Signed-off-by: default avatarzhong jiang <zhongjiang@huawei.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      cd5ff945
    • Naveen N. Rao's avatar
      powerpc/pseries: Fix how we iterate over the DTL entries · 9258227e
      Naveen N. Rao authored
      When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set, we look up dtl_idx in
      the lppaca to determine the number of entries in the buffer. Since
      lppaca is in big endian, we need to do an endian conversion before using
      this in our calculation to determine the number of entries in the
      buffer. Without this, we do not iterate over the existing entries in the
      DTL buffer properly.
      
      Fixes: 7c105b63 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.")
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      9258227e
    • Naveen N. Rao's avatar
      powerpc/pseries: Fix DTL buffer registration · db787af1
      Naveen N. Rao authored
      When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set, we register the DTL
      buffer for a cpu when the associated file under powerpc/dtl in debugfs
      is opened. When doing so, we need to set the size of the buffer being
      registered in the second u32 word of the buffer. This needs to be in big
      endian, but we are not doing the conversion resulting in the below error
      showing up in dmesg:
      
      	dtl_start: DTL registration for cpu 0 (hw 0) failed with -4
      
      Fix this in the obvious manner.
      
      Fixes: 7c105b63 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.")
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      db787af1