All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Neuling <mikey@neuling.org>
To: Sam Bobroff <sam.bobroff@au1.ibm.com>
Cc: azanella@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org,
	matt@ozlabs.org
Subject: Re: [PATCH 1/3] powerpc/tm: Abort syscalls in active transactions
Date: Thu, 19 Mar 2015 16:01:54 +1100	[thread overview]
Message-ID: <1426741314.4866.100.camel@neuling.org> (raw)
In-Reply-To: <6ebcb9f982f7cb100aef954cd7dc6a6081cd9134.1426740212.git.sam.bobroff@au1.ibm.com>

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 <sam.bobroff@au1.ibm.com>

Thanks Sam!

Acked-By: Michael Neuling <mikey@neuling.org>

> ---
>  Documentation/powerpc/transactional_memory.txt |   33 ++++++++++++------=
------
>  arch/powerpc/include/uapi/asm/tm.h             |    2 +-
>  arch/powerpc/kernel/entry_64.S                 |   19 ++++++++++++++
>  3 files changed, 37 insertions(+), 17 deletions(-)
>=20
> diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentati=
on/powerpc/transactional_memory.txt
> index 9791e98..4167bc2 100644
> --- a/Documentation/powerpc/transactional_memory.txt
> +++ b/Documentation/powerpc/transactional_memory.txt
> @@ -74,22 +74,23 @@ Causes of transaction aborts
>  Syscalls
>  =3D=3D=3D=3D=3D=3D=3D=3D
> =20
> -Performing syscalls from within transaction is not recommended, and can =
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).
> +Examples are glibc's getpid() and lazy symbol resolution.
> =20
>=20
>  Signals
> diff --git a/arch/powerpc/include/uapi/asm/tm.h b/arch/powerpc/include/ua=
pi/asm/tm.h
> index 5d836b7..5047659 100644
> --- a/arch/powerpc/include/uapi/asm/tm.h
> +++ b/arch/powerpc/include/uapi/asm/tm.h
> @@ -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
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_6=
4.S
> index d180caf2..85bf81d 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -34,6 +34,7 @@
>  #include <asm/ftrace.h>
>  #include <asm/hw_irq.h>
>  #include <asm/context_tracking.h>
> +#include <asm/tm.h>
> =20
>  /*
>   * System calls.
> @@ -145,6 +146,24 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
>  	andi.	r11,r10,_TIF_SYSCALL_DOTRACE
>  	bne	syscall_dotrace
>  .Lsyscall_dotrace_cont:
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> +BEGIN_FTR_SECTION
> +	b	1f
> +END_FTR_SECTION_IFCLR(CPU_FTR_TM)
> +	extrdi.	r11, r12, 1, (63-MSR_TS_T_LG) /* transaction active? */
> +	beq+	1f
> +
> +	/* Doom the transaction and don't perform the syscall: */
> +	mfmsr	r11
> +	li	r12, 1
> +	rldimi	r11, r12, MSR_TM_LG, 63-MSR_TM_LG
> +	mtmsrd	r11, 0
> +	li	r11, (TM_CAUSE_SYSCALL|TM_CAUSE_PERSISTENT)
> +	tabort. r11
> +
> +	b	.Lsyscall_exit
> +1:
> +#endif
>  	cmpldi	0,r0,NR_syscalls
>  	bge-	syscall_enosys
> =20

  reply	other threads:[~2015-03-19  5:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19  4:43 [PATCH 0/3] powerpc/tm: Abort syscalls in active transactions Sam Bobroff
2015-03-19  4:43 ` [PATCH 1/3] " Sam Bobroff
2015-03-19  5:01   ` Michael Neuling [this message]
2015-03-20  9:04   ` Anshuman Khandual
2015-03-24  2:04     ` Michael Ellerman
2015-03-24  4:26       ` Anshuman Khandual
2015-03-24 13:02         ` Michael Ellerman
2015-03-19  4:43 ` [PATCH 2/3] selftests/powerpc: Move get_auxv_entry() to harness.c Sam Bobroff
2015-03-19  4:43 ` [PATCH 3/3] selftests/powerpc: Add transactional syscall test Sam Bobroff
2015-03-20  9:25   ` Anshuman Khandual
2015-03-24  1:52     ` Sam Bobroff
2015-03-24  2:02       ` Michael Ellerman
2015-03-30  0:06         ` Sam Bobroff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1426741314.4866.100.camel@neuling.org \
    --to=mikey@neuling.org \
    --cc=azanella@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matt@ozlabs.org \
    --cc=sam.bobroff@au1.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.