1. 19 Sep, 2018 24 commits
  2. 17 Sep, 2018 7 commits
  3. 14 Sep, 2018 2 commits
    • Alan Modra's avatar
      powerpc/vdso: Correct call frame information · 56d20861
      Alan Modra authored
      Call Frame Information is used by gdb for back-traces and inserting
      breakpoints on function return for the "finish" command.  This failed
      when inside __kernel_clock_gettime.  More concerning than difficulty
      debugging is that CFI is also used by stack frame unwinding code to
      implement exceptions.  If you have an app that needs to handle
      asynchronous exceptions for some reason, and you are unlucky enough to
      get one inside the VDSO time functions, your app will crash.
      
      What's wrong:  There is control flow in __kernel_clock_gettime that
      reaches label 99 without saving lr in r12.  CFI info however is
      interpreted by the unwinder without reference to control flow: It's a
      simple matter of "Execute all the CFI opcodes up to the current
      address".  That means the unwinder thinks r12 contains the return
      address at label 99.  Disabuse it of that notion by resetting CFI for
      the return address at label 99.
      
      Note that the ".cfi_restore lr" could have gone anywhere from the
      "mtlr r12" a few instructions earlier to the instruction at label 99.
      I put the CFI as late as possible, because in general that's best
      practice (and if possible grouped with other CFI in order to reduce
      the number of CFI opcodes executed when unwinding).  Using r12 as the
      return address is perfectly fine after the "mtlr r12" since r12 on
      that code path still contains the return address.
      
      __get_datapage also has a CFI error.  That function temporarily saves
      lr in r0, and reflects that fact with ".cfi_register lr,r0".  A later
      use of r0 means the CFI at that point isn't correct, as r0 no longer
      contains the return address.  Fix that too.
      Signed-off-by: default avatarAlan Modra <amodra@gmail.com>
      Tested-by: default avatarReza Arbab <arbab@linux.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      56d20861
    • Michael Neuling's avatar
      powerpc/tm: Fix HFSCR bit for no suspend case · dd9a8c5a
      Michael Neuling authored
      Currently on P9N DD2.1 we end up taking infinite TM facility
      unavailable exceptions on the first TM usage by userspace.
      
      In the special case of TM no suspend (P9N DD2.1), Linux is told TM is
      off via CPU dt-ftrs but told to (partially) use it via
      OPAL_REINIT_CPUS_TM_SUSPEND_DISABLED. So HFSCR[TM] will be off from
      dt-ftrs but we need to turn it on for the no suspend case.
      
      This patch fixes this by enabling HFSCR TM in this case.
      
      Cc: stable@vger.kernel.org # 4.15+
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      dd9a8c5a
  4. 10 Sep, 2018 1 commit
  5. 09 Sep, 2018 6 commits