1. 29 Aug, 2016 1 commit
    • Cyril Bur's avatar
      powerpc: signals: Discard transaction state from signal frames · 78a3e888
      Cyril Bur authored
      Userspace can begin and suspend a transaction within the signal
      handler which means they might enter sys_rt_sigreturn() with the
      processor in suspended state.
      sys_rt_sigreturn() wants to restore process context (which may have
      been in a transaction before signal delivery). To do this it must
      restore TM SPRS. To achieve this, any transaction initiated within the
      signal frame must be discarded in order to be able to restore TM SPRs
      as TM SPRs can only be manipulated non-transactionally..
      >From the PowerPC ISA:
        TM Bad Thing Exception [Category: Transactional Memory]
         An attempt is made to execute a mtspr targeting a TM register in
         other than Non-transactional state.
      Not doing so results in a TM Bad Thing:
      [12045.221359] Kernel BUG at c000000000050a40 [verbose debug info unavailable]
      [12045.221470] Unexpected TM Bad Thing exception at c000000000050a40 (msr 0x201033)
      [12045.221540] Oops: Unrecoverable exception, sig: 6 [#1]
      [12045.221586] SMP NR_CPUS=2048 NUMA PowerNV
      [12045.221634] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE
       nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
       xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter
       ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables kvm_hv kvm
       uio_pdrv_genirq ipmi_powernv uio powernv_rng ipmi_msghandler autofs4 ses enclosure
       scsi_transport_sas bnx2x ipr mdio libcrc32c
      [12045.222167] CPU: 68 PID: 6178 Comm: sigreturnpanic Not tainted 4.7.0 #34
      [12045.222224] task: c0000000fce38600 ti: c0000000fceb4000 task.ti: c0000000fceb4000
      [12045.222293] NIP: c000000000050a40 LR: c0000000000163bc CTR: 0000000000000000
      [12045.222361] REGS: c0000000fceb7ac0 TRAP: 0700   Not tainted (4.7.0)
      [12045.222418] MSR: 9000000300201033 <SF,HV,ME,IR,DR,RI,LE,TM[SE]> CR: 28444280  XER: 20000000
      [12045.222625] CFAR: c0000000000163b8 SOFTE: 0 PACATMSCRATCH: 900000014280f033
      GPR00: 01100000b8000001 c0000000fceb7d40 c00000000139c100 c0000000fce390d0
      GPR04: 900000034280f033 0000000000000000 0000000000000000 0000000000000000
      GPR08: 0000000000000000 b000000000001033 0000000000000001 0000000000000000
      GPR12: 0000000000000000 c000000002926400 0000000000000000 0000000000000000
      GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
      GPR24: 0000000000000000 00003ffff98cadd0 00003ffff98cb470 0000000000000000
      GPR28: 900000034280f033 c0000000fceb7ea0 0000000000000001 c0000000fce390d0
      [12045.223535] NIP [c000000000050a40] tm_restore_sprs+0xc/0x1c
      [12045.223584] LR [c0000000000163bc] tm_recheckpoint+0x5c/0xa0
      [12045.223630] Call Trace:
      [12045.223655] [c0000000fceb7d80] [c000000000026e74] sys_rt_sigreturn+0x494/0x6c0
      [12045.223738] [c0000000fceb7e30] [c0000000000092e0] system_call+0x38/0x108
      [12045.223806] Instruction dump:
      [12045.223841] 7c800164 4e800020 7c0022a6 f80304a8 7c0222a6 f80304b0 7c0122a6 f80304b8
      [12045.223955] 4e800020 e80304a8 7c0023a6 e80304b0 <7c0223a6> e80304b8 7c0123a6 4e800020
      [12045.224074] ---[ end trace cb8002ee240bae76 ]---
      It isn't clear exactly if there is really a use case for userspace
      returning with a suspended transaction, however, doing so doesn't (on
      its own) constitute a bad frame. As such, this patch simply discards
      the transactional state of the context calling the sigreturn and
      Reported-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Signed-off-by: default avatarCyril Bur <cyrilbur@gmail.com>
      Tested-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Reviewed-by: default avatarLaurent Dufour <ldufour@linux.vnet.ibm.com>
      Acked-by: default avatarSimon Guo <wei.guo.simon@gmail.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
  2. 19 Jun, 2015 1 commit
    • Sam bobroff's avatar
      powerpc/tm: Abort syscalls in active transactions · b4b56f9e
      Sam bobroff authored
      This patch changes the syscall handler to doom (tabort) active
      transactions when a syscall is made and return very early without
      performing the syscall and keeping side effects to a minimum (no CPU
      accounting or system call tracing is performed). Also included is a
      new HWCAP2 bit, PPC_FEATURE2_HTM_NOSC, to indicate this
      behaviour to userspace.
      Currently, the system call instruction automatically suspends an
      active transaction which causes side effects to persist when an active
      transaction fails.
      This does change the kernel's behaviour, but in a way that was
      documented as unsupported.  It doesn't reduce functionality as
      syscalls will still be performed after tsuspend; it just requires that
      the transaction be explicitly suspended.  It also provides a
      consistent interface and makes the behaviour of user code
      substantially the same across powerpc and platforms that do not
      support suspended transactions (e.g. x86 and s390).
      Performance measurements using
      http://ozlabs.org/~anton/junkcode/null_syscall.c indicate the cost of
      a normal (non-aborted) system call increases by about 0.25%.
      Signed-off-by: default avatarSam Bobroff <sam.bobroff@au1.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  3. 30 Apr, 2015 1 commit
    • Michael Ellerman's avatar
      Revert "powerpc/tm: Abort syscalls in active transactions" · 68fc378c
      Michael Ellerman authored
      This reverts commit feba4036.
      Although the principle of this change is good, the implementation has a
      few issues.
      Firstly we can sometimes fail to abort a syscall because r12 may have
      been clobbered by C code if we went down the virtual CPU accounting
      path, or if syscall tracing was enabled.
      Secondly we have decided that it is safer to abort the syscall even
      earlier in the syscall entry path, so that we avoid the syscall tracing
      path when we are transactional.
      So that we have time to thoroughly test those changes we have decided to
      revert this for this merge window and will merge the fixed version in
      the next window.
      NB. Rather than reverting the selftest we just drop tm-syscall from
      TEST_PROGS so that it's not run by default.
      Fixes: feba4036 ("powerpc/tm: Abort syscalls in active transactions")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
  4. 11 Apr, 2015 2 commits
  5. 05 May, 2014 1 commit
  6. 31 May, 2013 3 commits
    • Michael Neuling's avatar
      powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions · 2b3f8e87
      Michael Neuling authored
      When in an active transaction that takes a signal, we need to be careful with
      the stack.  It's possible that the stack has moved back up after the tbegin.
      The obvious case here is when the tbegin is called inside a function that
      returns before a tend.  In this case, the stack is part of the checkpointed
      transactional memory state.  If we write over this non transactionally or in
      suspend, we are in trouble because if we get a tm abort, the program counter
      and stack pointer will be back at the tbegin but our in memory stack won't be
      valid anymore.
      To avoid this, when taking a signal in an active transaction, we need to use
      the stack pointer from the checkpointed state, rather than the speculated
      state.  This ensures that the signal context (written tm suspended) will be
      written below the stack required for the rollback.  The transaction is aborted
      becuase of the treclaim, so any memory written between the tbegin and the
      signal will be rolled back anyway.
      For signals taken in non-TM or suspended mode, we use the
      normal/non-checkpointed stack pointer.
      Tested with 64 and 32 bit signals
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Michael Neuling's avatar
      powerpc/tm: Abort on emulation and alignment faults · 6ce6c629
      Michael Neuling authored
      If we are emulating an instruction inside an active user transaction that
      touches memory, the kernel can't emulate it as it operates in transactional
      suspend context.  We need to abort these transactions and send them back to
      userspace for the hardware to rollback.
      We can service these if the user transaction is in suspend mode, since the
      kernel will operate in the same suspend context.
      This adds a check to all alignment faults and to specific instruction
      emulations (only string instructions for now).  If the user process is in an
      active (non-suspended) transaction, we abort the transaction go back to
      userspace allowing the HW to roll back the transaction and tell the user of the
      failure.  This also adds new tm abort cause codes to report the reason of the
      persistent error to the user.
      Crappy test case here http://neuling.org/devel/junkcode/aligntm.cSigned-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # v3.9
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    • Michael Neuling's avatar
      powerpc/tm: Update cause codes documentation · 24b92375
      Michael Neuling authored
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Cc: <stable@vger.kernel.org> # 3.9 only
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
  7. 15 Feb, 2013 1 commit