Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit b4b56f9e authored by Sam bobroff's avatar Sam bobroff Committed by Michael Ellerman
Browse files

powerpc/tm: Abort syscalls in active transactions 

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>
parent b5926430

Documentation/powerpc/transactional_memory.txt

+16 −16
Original line number Diff line number Diff line
@@ -74,22 +74,23 @@ Causes of transaction aborts 
Syscalls

========



Performing syscalls from within transaction is not recommended, and can lead

to unpredictable results.

Syscalls made from within an active transaction will not be performed and the

transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL

| TM_CAUSE_PERSISTENT.



Syscalls do not by design abort transactions, but beware: The kernel code will

not be running in transactional state.  The effect of syscalls will always

remain visible, but depending on the call they may abort your transaction as a

side-effect, read soon-to-be-aborted transactional data that should not remain

invisible, etc.  If you constantly retry a transaction that constantly aborts

itself by calling a syscall, you'll have a livelock & make no progress.

Syscalls made from within a suspended transaction are performed as normal and

the transaction is not explicitly doomed by the kernel.  However, what the

kernel does to perform the syscall may result in the transaction being doomed

by the hardware.  The syscall is performed in suspended mode so any side

effects will be persistent, independent of transaction success or failure.  No

guarantees are provided by the kernel about which syscalls will affect

transaction success.



Simple syscalls (e.g. sigprocmask()) "could" be OK.  Even things like write()

from, say, printf() should be OK as long as the kernel does not access any

memory that was accessed transactionally.



Consider any syscalls that happen to work as debug-only -- not recommended for

production use.  Best to queue them up till after the transaction is over.

Care must be taken when relying on syscalls to abort during active transactions

if the calls are made via a library.  Libraries may cache values (which may

give the appearance of success) or perform operations that cause transaction

failure before entering the kernel (which may produce different failure codes).

Examples are glibc's getpid() and lazy symbol resolution.





Signals
@@ -176,8 +177,7 @@ 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       Currently unused; future syscalls that must abort

                        transactions for consistency will use this.

 TM_CAUSE_SYSCALL       Syscall from active transaction.

 TM_CAUSE_SIGNAL        Signal delivered.

 TM_CAUSE_MISC          Currently unused.

 TM_CAUSE_ALIGNMENT     Alignment fault.

arch/powerpc/include/asm/cputable.h

+6 −4
Original line number Diff line number Diff line
@@ -244,9 +244,11 @@ enum { 
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM

#define CPU_FTR_TM_COMP			CPU_FTR_TM

#define PPC_FEATURE2_HTM_COMP		PPC_FEATURE2_HTM

#define PPC_FEATURE2_HTM_NOSC_COMP	PPC_FEATURE2_HTM_NOSC

#else

#define CPU_FTR_TM_COMP			0

#define PPC_FEATURE2_HTM_COMP		0

#define PPC_FEATURE2_HTM_NOSC_COMP	0

#endif



/* We need to mark all pages as being coherent if we're SMP or we have a

arch/powerpc/include/uapi/asm/cputable.h

+1 −0
Original line number Diff line number Diff line
@@ -42,5 +42,6 @@ 
#define PPC_FEATURE2_ISEL		0x08000000

#define PPC_FEATURE2_TAR		0x04000000

#define PPC_FEATURE2_VEC_CRYPTO		0x02000000

#define PPC_FEATURE2_HTM_NOSC		0x01000000



#endif /* _UAPI__ASM_POWERPC_CPUTABLE_H */

arch/powerpc/include/uapi/asm/tm.h

+1 −1
Original line number Diff line number Diff line
@@ -11,7 +11,7 @@ 
#define TM_CAUSE_RESCHED	0xde

#define TM_CAUSE_TLBI		0xdc

#define TM_CAUSE_FAC_UNAV	0xda

#define TM_CAUSE_SYSCALL	0xd8  /* future use */

#define TM_CAUSE_SYSCALL	0xd8

#define TM_CAUSE_MISC		0xd6  /* future use */

#define TM_CAUSE_SIGNAL		0xd4

#define TM_CAUSE_ALIGNMENT	0xd2

arch/powerpc/kernel/cputable.c

+3 −1
Original line number Diff line number Diff line
@@ -108,7 +108,9 @@ extern void __restore_cpu_e6500(void); 
				 PPC_FEATURE_TRUE_LE | \

				 PPC_FEATURE_PSERIES_PERFMON_COMPAT)

#define COMMON_USER2_POWER8	(PPC_FEATURE2_ARCH_2_07 | \

				 PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_DSCR | \

				 PPC_FEATURE2_HTM_COMP | \

				 PPC_FEATURE2_HTM_NOSC_COMP | \

				 PPC_FEATURE2_DSCR | \

				 PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR | \

				 PPC_FEATURE2_VEC_CRYPTO)

#define COMMON_USER_PA6T	(COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\