1. 23 Jun, 2017 2 commits
    • Christophe Lombard's avatar
      cxl: Fixes for Coherent Accelerator Interface Architecture 2.0 · 797625de
      Christophe Lombard authored
      A previous set of patches "cxl: Add support for Coherent Accelerator
      Interface Architecture 2.0" has introduced a new support for the CAPI
      cards. These patches have been tested on Simulation environment and
      quite a bit of them have been tested on real hardware.
      
      This patch brings new fixes after a series of tests carried out on new
      equipment:
        - Add POWER9 definition.
        - Re-enable any masked interrupts when the AFU is not activated
          after resetting the AFU.
        - Remove the api cxl_is_psl8/9 which is no longer useful.
        - Do not dump CAPI1 registers.
        - Rewrite cxl_is_page_fault() function.
        - Do not register slb callack on P9.
      
      Fixes: f24be42a ("cxl: Add psl9 specific code")
      Signed-off-by: default avatarChristophe Lombard <clombard@linux.vnet.ibm.com>
      Acked-by: default avatarFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      797625de
    • Nicholas Piggin's avatar
      powerpc/64: Initialise thread_info for emergency stacks · 34f19ff1
      Nicholas Piggin authored
      Emergency stacks have their thread_info mostly uninitialised, which in
      particular means garbage preempt_count values.
      
      Emergency stack code runs with interrupts disabled entirely, and is
      used very rarely, so this has been unnoticed so far. It was found by a
      proposed new powerpc watchdog that takes a soft-NMI directly from the
      masked_interrupt handler and using the emergency stack. That crashed
      at BUG_ON(in_nmi()) in nmi_enter(). preempt_count()s were found to be
      garbage.
      
      To fix this, zero the entire THREAD_SIZE allocation, and initialize
      the thread_info.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAbdul Haleem <abdhalee@linux.vnet.ibm.com>
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      [mpe: Move it all into setup_64.c, use a function not a macro. Fix
            crashes on Cell by setting preempt_count to 0 not HARDIRQ_OFFSET]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      34f19ff1
  2. 22 Jun, 2017 1 commit
  3. 16 Jun, 2017 6 commits
    • Ravi Bangoria's avatar
      powerpc/perf: Fix oops when kthread execs user process · bf05fc25
      Ravi Bangoria authored
      When a kthread calls call_usermodehelper() the steps are:
        1. allocate current->mm
        2. load_elf_binary()
        3. populate current->thread.regs
      
      While doing this, interrupts are not disabled. If there is a perf
      interrupt in the middle of this process (i.e. step 1 has completed
      but not yet reached to step 3) and if perf tries to read userspace
      regs, kernel oops with following log:
      
        Unable to handle kernel paging request for data at address 0x00000000
        Faulting instruction address: 0xc0000000000da0fc
        ...
        Call Trace:
        perf_output_sample_regs+0x6c/0xd0
        perf_output_sample+0x4e4/0x830
        perf_event_output_forward+0x64/0x90
        __perf_event_overflow+0x8c/0x1e0
        record_and_restart+0x220/0x5c0
        perf_event_interrupt+0x2d8/0x4d0
        performance_monitor_exception+0x54/0x70
        performance_monitor_common+0x158/0x160
        --- interrupt: f01 at avtab_search_node+0x150/0x1a0
            LR = avtab_search_node+0x100/0x1a0
        ...
        load_elf_binary+0x6e8/0x15a0
        search_binary_handler+0xe8/0x290
        do_execveat_common.isra.14+0x5f4/0x840
        call_usermodehelper_exec_async+0x170/0x210
        ret_from_kernel_thread+0x5c/0x7c
      
      Fix it by setting abi to PERF_SAMPLE_REGS_ABI_NONE when userspace
      pt_regs are not set.
      
      Fixes: ed4a4ef8 ("powerpc/perf: Add support for sampling interrupt register state")
      Cc: stable@vger.kernel.org # v4.7+
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      bf05fc25
    • Naveen N. Rao's avatar
      powerpc/64s: Handle data breakpoints in Radix mode · d89ba535
      Naveen N. Rao authored
      On Power9, trying to use data breakpoints throws the splat shown
      below. This is because the check for a data breakpoint in DSISR is in
      do_hash_page(), which is not called when in Radix mode.
      
        Unable to handle kernel paging request for data at address 0xc000000000e19218
        Faulting instruction address: 0xc0000000001155e8
        cpu 0x0: Vector: 300 (Data Access) at [c0000000ef1e7b20]
        pc: c0000000001155e8: find_pid_ns+0x48/0xe0
        lr: c000000000116ac4: find_task_by_vpid+0x44/0x90
        sp: c0000000ef1e7da0
        msr: 9000000000009033
        dar: c000000000e19218
        dsisr: 400000
      
      Move the check to handle_page_fault() so as to catch data breakpoints
      in both Hash and Radix MMU modes.
      
      We have to change the check in do_hash_page() against 0xa410 to use
      0xa450, so as to include the value of (DSISR_DABRMATCH << 16).
      
      There are two sites that call handle_page_fault() when in Radix, both
      already pass DSISR in r4.
      
      Fixes: caca285e ("powerpc/mm/radix: Use STD_MMU_64 to properly isolate hash related code")
      Cc: stable@vger.kernel.org # v4.7+
      Reported-by: default avatarShriya R. Kulkarni <shriykul@in.ibm.com>
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      [mpe: Fix the fall-through case on hash, we need to reload DSISR]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      d89ba535
    • Naveen N. Rao's avatar
      powerpc/kprobes: Skip livepatch_handler() for jprobes · c05b8c44
      Naveen N. Rao authored
      ftrace_caller() depends on a modified regs->nip to detect if a certain
      function has been livepatched. However, with KPROBES_ON_FTRACE, it is
      possible for regs->nip to have been modified by the kprobes pre_handler
      (jprobes, for instance). In this case, we do not want to invoke the
      livepatch_handler so as not to consume the livepatch stack.
      
      To distinguish between the two (kprobes and livepatch), we check if
      there is an active kprobe on the current function. If there is, then we
      know for sure that it must have modified the NIP as we don't support
      livepatching a kprobe'd function. In this case, we simply skip the
      livepatch_handler and branch to the new NIP. Otherwise, the
      livepatch_handler is invoked.
      
      Fixes: ead514d5 ("powerpc/kprobes: Add support for KPROBES_ON_FTRACE")
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      c05b8c44
    • Naveen N. Rao's avatar
      powerpc/ftrace: Pass the correct stack pointer for DYNAMIC_FTRACE_WITH_REGS · a4979a7e
      Naveen N. Rao authored
      For DYNAMIC_FTRACE_WITH_REGS, we should be passing-in the original set
      of registers in pt_regs, to capture the state _before_ ftrace_caller.
      However, we are instead passing the stack pointer *after* allocating a
      stack frame in ftrace_caller. Fix this by saving the proper value of r1
      in pt_regs. Also, use SAVE_10GPRS() to simplify the code.
      
      Fixes: 15308664 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI")
      Cc: stable@vger.kernel.org # v4.6+
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      a4979a7e
    • Naveen N. Rao's avatar
      powerpc/kprobes: Pause function_graph tracing during jprobes handling · a9f8553e
      Naveen N. Rao authored
      This fixes a crash when function_graph and jprobes are used together.
      This is essentially commit 237d28db ("ftrace/jprobes/x86: Fix
      conflict between jprobes and function graph tracing"), but for powerpc.
      
      Jprobes breaks function_graph tracing since the jprobe hook needs to use
      jprobe_return(), which never returns back to the hook, but instead to
      the original jprobe'd function. The solution is to momentarily pause
      function_graph tracing before invoking the jprobe hook and re-enable it
      when returning back to the original jprobe'd function.
      
      Fixes: 6794c782 ("powerpc64: port of the function graph tracer")
      Cc: stable@vger.kernel.org # v2.6.30+
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      a9f8553e
    • Alexey Kardashevskiy's avatar
      powerpc/debug: Add missing warn flag to WARN_ON's non-builtin path · a093c92d
      Alexey Kardashevskiy authored
      When trapped on WARN_ON(), report_bug() is expected to return
      BUG_TRAP_TYPE_WARN so the caller will increment NIP by 4 and continue.
      The __builtin_constant_p() path of the PPC's WARN_ON()
      calls (indirectly) __WARN_FLAGS() which has BUGFLAG_WARNING set,
      however the other branch does not which makes report_bug() report a
      bug rather than a warning.
      
      Fixes: f26dee15 ("debug: Avoid setting BUGFLAG_WARNING twice")
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      a093c92d
  4. 15 Jun, 2017 1 commit
  5. 14 Jun, 2017 1 commit
  6. 08 Jun, 2017 3 commits
  7. 06 Jun, 2017 4 commits
    • Madhavan Srinivasan's avatar
      powerpc/perf: Fix Power9 test_adder fields · 8c218578
      Madhavan Srinivasan authored
      Commit 8d911904 ('powerpc/perf: Add restrictions to PMC5 in power9 DD1')
      was added to restrict the use of PMC5 in Power9 DD1. Intention was to disable
      the use of PMC5 using raw event code. But instead of updating the
      power9_isa207_pmu structure (used on DD1), the commit incorrectly updated the
      power9_pmu structure. Fix it.
      
      Fixes: 8d911904 ("powerpc/perf: Add restrictions to PMC5 in power9 DD1")
      Reported-by: default avatarShriya <shriyak@linux.vnet.ibm.com>
      Signed-off-by: default avatarMadhavan Srinivasan <maddy@linux.vnet.ibm.com>
      Tested-by: default avatarShriya <shriyak@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      8c218578
    • Michael Ellerman's avatar
      powerpc/numa: Fix percpu allocations to be NUMA aware · ba4a648f
      Michael Ellerman authored
      In commit 8c272261 ("powerpc/numa: Enable USE_PERCPU_NUMA_NODE_ID"), we
      switched to the generic implementation of cpu_to_node(), which uses a percpu
      variable to hold the NUMA node for each CPU.
      
      Unfortunately we neglected to notice that we use cpu_to_node() in the allocation
      of our percpu areas, leading to a chicken and egg problem. In practice what
      happens is when we are setting up the percpu areas, cpu_to_node() reports that
      all CPUs are on node 0, so we allocate all percpu areas on node 0.
      
      This is visible in the dmesg output, as all pcpu allocs being in group 0:
      
        pcpu-alloc: [0] 00 01 02 03 [0] 04 05 06 07
        pcpu-alloc: [0] 08 09 10 11 [0] 12 13 14 15
        pcpu-alloc: [0] 16 17 18 19 [0] 20 21 22 23
        pcpu-alloc: [0] 24 25 26 27 [0] 28 29 30 31
        pcpu-alloc: [0] 32 33 34 35 [0] 36 37 38 39
        pcpu-alloc: [0] 40 41 42 43 [0] 44 45 46 47
      
      To fix it we need an early_cpu_to_node() which can run prior to percpu being
      setup. We already have the numa_cpu_lookup_table we can use, so just plumb it
      in. With the patch dmesg output shows two groups, 0 and 1:
      
        pcpu-alloc: [0] 00 01 02 03 [0] 04 05 06 07
        pcpu-alloc: [0] 08 09 10 11 [0] 12 13 14 15
        pcpu-alloc: [0] 16 17 18 19 [0] 20 21 22 23
        pcpu-alloc: [1] 24 25 26 27 [1] 28 29 30 31
        pcpu-alloc: [1] 32 33 34 35 [1] 36 37 38 39
        pcpu-alloc: [1] 40 41 42 43 [1] 44 45 46 47
      
      We can also check the data_offset in the paca of various CPUs, with the fix we
      see:
      
        CPU 0:  data_offset = 0x0ffe8b0000
        CPU 24: data_offset = 0x1ffe5b0000
      
      And we can see from dmesg that CPU 24 has an allocation on node 1:
      
        node   0: [mem 0x0000000000000000-0x0000000fffffffff]
        node   1: [mem 0x0000001000000000-0x0000001fffffffff]
      
      Cc: stable@vger.kernel.org # v3.16+
      Fixes: 8c272261 ("powerpc/numa: Enable USE_PERCPU_NUMA_NODE_ID")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      ba4a648f
    • Vaibhav Jain's avatar
      cxl: Avoid double free_irq() for psl,slice interrupts · b3aa20ba
      Vaibhav Jain authored
      During an eeh call to cxl_remove can result in double free_irq of
      psl,slice interrupts. This can happen if perst_reloads_same_image == 1
      and call to cxl_configure_adapter() fails during slot_reset
      callback. In such a case we see a kernel oops with following back-trace:
      
      Oops: Kernel access of bad area, sig: 11 [#1]
      Call Trace:
        free_irq+0x88/0xd0 (unreliable)
        cxl_unmap_irq+0x20/0x40 [cxl]
        cxl_native_release_psl_irq+0x78/0xd8 [cxl]
        pci_deconfigure_afu+0xac/0x110 [cxl]
        cxl_remove+0x104/0x210 [cxl]
        pci_device_remove+0x6c/0x110
        device_release_driver_internal+0x204/0x2e0
        pci_stop_bus_device+0xa0/0xd0
        pci_stop_and_remove_bus_device+0x28/0x40
        pci_hp_remove_devices+0xb0/0x150
        pci_hp_remove_devices+0x68/0x150
        eeh_handle_normal_event+0x140/0x580
        eeh_handle_event+0x174/0x360
        eeh_event_handler+0x1e8/0x1f0
      
      This patch fixes the issue of double free_irq by checking that
      variables that hold the virqs (err_hwirq, serr_hwirq, psl_virq) are
      not '0' before un-mapping and resetting these variables to '0' when
      they are un-mapped.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Reviewed-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      b3aa20ba
    • Breno Leitao's avatar
      powerpc/kernel: Initialize load_tm on task creation · 7f22ced4
      Breno Leitao authored
      Currently tsk->thread.load_tm is not initialized in the task creation
      and can contain garbage on a new task.
      
      This is an undesired behaviour, since it affects the timing to enable
      and disable the transactional memory laziness (disabling and enabling
      the MSR TM bit, which affects TM reclaim and recheckpoint in the
      scheduling process).
      
      Fixes: 5d176f75 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace")
      Cc: stable@vger.kernel.org # v4.9+
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      7f22ced4
  8. 05 Jun, 2017 1 commit
    • Breno Leitao's avatar
      powerpc/kernel: Fix FP and vector register restoration · 1195892c
      Breno Leitao authored
      Currently tsk->thread->load_vec and load_fp are not initialized during
      task creation, which can lead to garbage values in these variables (non-zero
      values).
      
      These variables will be checked later in restore_math() to validate if the
      FP and vector registers are being utilized. Since these values might be
      non-zero, the restore_math() will continue to save the FP and vectors even if
      they were never utilized by the userspace application. load_fp and load_vec
      counters will then overflow (they wrap at 255) and the FP and Altivec will be
      finally disabled, but before that condition is reached (counter overflow)
      several context switches will have restored FP and vector registers without
      need, causing a performance degradation.
      
      Fixes: 70fe3d98 ("powerpc: Restore FPU/VEC/VSX if previously used")
      Cc: stable@vger.kernel.org # v4.6+
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarGustavo Romero <gusbromero@gmail.com>
      Acked-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      1195892c
  9. 01 Jun, 2017 5 commits
  10. 25 May, 2017 4 commits
  11. 19 May, 2017 2 commits
    • Michael Ellerman's avatar
      selftests/powerpc: Fix TM resched DSCR test with some compilers · fe06fe86
      Michael Ellerman authored
      The tm-resched-dscr test has started failing sometimes, depending on
      what compiler it's built with, eg:
      
        test: tm_resched_dscr
        Check DSCR TM context switch: tm-resched-dscr: tm-resched-dscr.c:76: test_body: Assertion `rv' failed.
        !! child died by signal 6
      
      When it fails we see that the compiler doesn't initialise rv to 1 before
      entering the inline asm block. Although that's counter intuitive, it
      is allowed because we tell the compiler that the inline asm will write
      to rv (using "=r"), meaning the original value is irrelevant.
      
      Marking it as a read/write parameter would presumably work, but it seems
      simpler to fix it by setting the initial value of rv in the inline asm.
      
      Fixes: 96d01610 ("powerpc: Correct DSCR during TM context switch")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarMichael Neuling <mikey@neuling.org>
      fe06fe86
    • Michael Ellerman's avatar
      powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash · e41e53cd
      Michael Ellerman authored
      virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on
      an address. What this means in practice is that it should only return true for
      addresses in the linear mapping which are backed by a valid PFN.
      
      We are failing to properly check that the address is in the linear mapping,
      because virt_to_pfn() will return a valid looking PFN for more or less any
      address. That bug is actually caused by __pa(), used in virt_to_pfn().
      
      eg: __pa(0xc000000000010000) = 0x10000  # Good
          __pa(0xd000000000010000) = 0x10000  # Bad!
          __pa(0x0000000000010000) = 0x10000  # Bad!
      
      This started happening after commit bdbc29c1 ("powerpc: Work around gcc
      miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition
      of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from
      the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give
      you something bogus back.
      
      Until we can verify if that GCC bug is no longer an issue, or come up with
      another solution, this commit does the minimal fix to make virt_addr_valid()
      work, by explicitly checking that the address is in the linear mapping region.
      
      Fixes: bdbc29c1 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Tested-by: default avatarBreno Leitao <breno.leitao@gmail.com>
      e41e53cd
  12. 17 May, 2017 1 commit
    • Michael Ellerman's avatar
      powerpc/mm: Fix crash in page table dump with huge pages · bfb9956a
      Michael Ellerman authored
      The page table dump code doesn't know about huge pages, so currently
      it crashes (or walks random memory, usually leading to a crash), if it
      finds a huge page. On Book3S we only see huge pages in the Linux page
      tables when we're using the P9 Radix MMU.
      
      Teaching the code to properly handle huge pages is a bit more involved,
      so for now just prevent the crash.
      
      Cc: stable@vger.kernel.org # v4.10+
      Fixes: 8eb07b18 ("powerpc/mm: Dump linux pagetables")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      bfb9956a
  13. 16 May, 2017 3 commits
  14. 15 May, 2017 2 commits
    • Michael Neuling's avatar
      powerpc/tm: Fix FP and VMX register corruption · f48e91e8
      Michael Neuling authored
      In commit dc310669 ("powerpc: tm: Always use fp_state and vr_state
      to store live registers"), a section of code was removed that copied
      the current state to checkpointed state. That code should not have been
      removed.
      
      When an FP (Floating Point) unavailable is taken inside a transaction,
      we need to abort the transaction. This is because at the time of the
      tbegin, the FP state is bogus so the state stored in the checkpointed
      registers is incorrect. To fix this, we treclaim (to get the
      checkpointed GPRs) and then copy the thread_struct FP live state into
      the checkpointed state. We then trecheckpoint so that the FP state is
      correctly restored into the CPU.
      
      The copying of the FP registers from live to checkpointed is what was
      missing.
      
      This simplifies the logic slightly from the original patch.
      tm_reclaim_thread() will now always write the checkpointed FP
      state. Either the checkpointed FP state will be written as part of
      the actual treclaim (in tm.S), or it'll be a copy of the live
      state. Which one we use is based on MSR[FP] from userspace.
      
      Similarly for VMX.
      
      Fixes: dc310669 ("powerpc: tm: Always use fp_state and vr_state to store live registers")
      Cc: stable@vger.kernel.org # 4.9+
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Reviewed-by: cyrilbur@gmail.com
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f48e91e8
    • Michael Ellerman's avatar
      powerpc/modules: If mprofile-kernel is enabled add it to vermagic · 43e24e82
      Michael Ellerman authored
      On powerpc we can build the kernel with two different ABIs for mcount(), which
      is used by ftrace. Kernels built with one ABI do not know how to load modules
      built with the other ABI. The new style ABI is called "mprofile-kernel", for
      want of a better name.
      
      Currently if we build a module using the old style ABI, and the kernel with
      mprofile-kernel, when we load the module we'll oops something like:
      
        # insmod autofs4-no-mprofile-kernel.ko
        ftrace-powerpc: Unexpected instruction f8810028 around bl _mcount
        ------------[ cut here ]------------
        WARNING: CPU: 6 PID: 3759 at ../kernel/trace/ftrace.c:2024 ftrace_bug+0x2b8/0x3c0
        CPU: 6 PID: 3759 Comm: insmod Not tainted 4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74 #11
        ...
        NIP [c0000000001eaa48] ftrace_bug+0x2b8/0x3c0
        LR [c0000000001eaff8] ftrace_process_locs+0x4a8/0x590
        Call Trace:
          alloc_pages_current+0xc4/0x1d0 (unreliable)
          ftrace_process_locs+0x4a8/0x590
          load_module+0x1c8c/0x28f0
          SyS_finit_module+0x110/0x140
          system_call+0x38/0xfc
        ...
        ftrace failed to modify
        [<d000000002a31024>] 0xd000000002a31024
         actual:   35:65:00:48
      
      We can avoid this by including in the vermagic whether the kernel/module was
      built with mprofile-kernel. Which results in:
      
        # insmod autofs4-pg.ko
        autofs4: version magic
        '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74 SMP mod_unload modversions '
        should be
        '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74-dirty SMP mod_unload modversions mprofile-kernel'
        insmod: ERROR: could not insert module autofs4-pg.ko: Invalid module format
      
      Fixes: 8c50b72a ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Acked-by: default avatarJessica Yu <jeyu@redhat.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      43e24e82
  15. 13 May, 2017 4 commits