On Thu, 2015-03-19 at 15:43 +1100, Sam Bobroff wrote:

This patch changes the syscall handler to doom (tabort) active
transactions when a syscall is made and return immediately without
performing the syscall.
=20
Currently, the system call instruction automatically suspends an
active transaction which causes side effects to persist when an active
transaction fails.
=20
This does change the kernel's behaviour, but in a way that was
documented as unsupported. It doesn't reduce functionality because
syscalls will still be performed after tsuspend. 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).
=20
Performance measurements using
http://ozlabs.org/~anton/junkcode/null_syscall.c
indicate the cost of a system call increases by about 0.5%.
=20
Signed-off-by: Sam Bobroff <redacted>

Thanks Sam!

Acked-By: Michael Neuling <redacted>

---
 Documentation/powerpc/transactional_memory.txt |   33 ++++++++++++------=

------

on/powerpc/transactional_memory.txt

lead

-to unpredictable results.
-
-Syscalls do not by design abort transactions, but beware: The kernel cod=

e will

-not be running in transactional state.  The effect of syscalls will alwa=

ys

-remain visible, but depending on the call they may abort your transactio=

n 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 a=

borts

-itself by calling a syscall, you'll have a livelock & make no progress.
-
-Simple syscalls (e.g. sigprocmask()) "could" be OK.  Even things like wr=

ite()

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

ny

-memory that was accessed transactionally.
-
-Consider any syscalls that happen to work as debug-only -- not recommend=

ed for

-production use.  Best to queue them up till after the transaction is ove=

r.

+Syscalls made from within an active transaction will not be performed an=

d the

+transaction will be doomed by the kernel with the failure code TM_CAUSE_=

SYSCALL

+| TM_CAUSE_PERSISTENT.
+
+Syscalls made from within a suspended transaction are performed as norma=

l and

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

he

+kernel does to perform the syscall may result in the transaction being d=

oomed

+by the hardware.  The syscall is performed in suspended mode so any side
+effects will be persistent, independent of transaction success or failur=

e.  No

+guarantees are provided by the kernel about which syscalls will affect
+transaction success.
+
+Care must be taken when relying on syscalls to abort during active trans=

actions

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

may

+give the appearence of success) or perform operations that cause transac=

tion

+failure before entering the kernel (which may produce different failure =

codes).

pi/asm/tm.h

4.S