Documentation/arch/powerpc/transactional_memory.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/powerpc/transactional_memory.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/powerpc/transactional_memory.rst
Extension
.rst
Size
11365 bytes
Lines
275
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

if (ucp_link) {
        u64 msr = ucp->uc_mcontext.regs->msr;
        /* May have transactional ucontext! */
  #ifndef __powerpc64__
        msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
  #endif
        if (MSR_TM_ACTIVE(msr)) {
           /* Yes, we crashed during a transaction.  Oops. */
   fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
                           "crashy instruction was at 0x%llx\n",
                           ucp->uc_mcontext.regs->nip,
                           transactional_ucp->uc_mcontext.regs->nip);
        }
      }

      fix_the_problem(ucp->dar);
    }

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
because 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.

Any transaction initiated inside a sighandler and suspended on return
from the sighandler to the kernel will get reclaimed and discarded.

Failure cause codes used by kernel
==================================

These are defined in <asm/reg.h>, and distinguish different reasons why the
kernel aborted a transaction:

 ====================== ================================
 TM_CAUSE_RESCHED       Thread was rescheduled.
 TM_CAUSE_TLBI          Software TLB invalid.
 TM_CAUSE_FAC_UNAV      FP/VEC/VSX unavailable trap.
 TM_CAUSE_SYSCALL       Syscall from active transaction.
 TM_CAUSE_SIGNAL        Signal delivered.
 TM_CAUSE_MISC          Currently unused.
 TM_CAUSE_ALIGNMENT     Alignment fault.
 TM_CAUSE_EMULATE       Emulation that touched memory.
 ====================== ================================

These can be checked by the user program's abort handler as TEXASR[0:7].  If
bit 7 is set, it indicates that the error is considered persistent.  For example
a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.

GDB
===

GDB and ptrace are not currently TM-aware.  If one stops during a transaction,
it looks like the transaction has just started (the checkpointed state is
presented).  The transaction cannot then be continued and will take the failure
handler route.  Furthermore, the transactional 2nd register state will be
inaccessible.  GDB can currently be used on programs using TM, but not sensibly
in parts within transactions.

Annotation

Implementation Notes