Thread (39 messages) flat view 39 messages, 2 authors, 2018-10-01

Re: [RFC PATCH 11/11] selftests/powerpc: Adapt the test

From: Michael Neuling <hidden>
Date: 2018-09-18 06:36:23

On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
The Documentation/powerpc/transactional_memory.txt says:
=20
 "Syscalls made from within a suspended transaction are performed as norm=
al
  and the transaction is not explicitly doomed by the kernel.  However,
  what the kernel does to perform the syscall may result in the transacti=
on
  being doomed by the hardware."
=20
With this new TM mechanism, the syscall will continue to be executed if t=
he
syscall happens on a suspended syscall, but, the syscall will *fail* if t=
he
transaction is still active during the syscall invocation.
Not sure I get this. This doesn't seem any different to before.

An active (not suspended) transaction *will* result in the syscall failing =
and
the transaction being doomed. =20

A syscall in a suspended transaction should succeed and the transaction.

You might need to clean up the language. I try to use:

   Active =3D=3D transactional but not suspended (ie MSR[TS] =3D T)
   Suspended =3D=3D suspended (ie MSR [TS] =3D S)
   Doomed =3D=3D transaction to be rolled back at next opportinity (ie tche=
ck returns doomed)

(note: the kernel MSR_TM_ACTIVE() macro is not consistent with this since i=
t's
MSR[TS] =3D=3D S or T).
On the syscall path, if the transaction is active and not suspended, it
will call TM_KERNEL_ENTRY which will reclaim and recheckpoint the
transaction, thus, dooming the transaction on userspace return, with
failure code TM_CAUSE_SYSCALL.
But the test below is on a suspend transaction?
This new model will break part of this test, but I understand that that t=
he
documentation above didn't guarantee that the syscall would succeed, and =
it
will never succeed anymore now on.
The syscall should pass in suspend (modulo the normal syscall checks). The
transaction may fail as a result.
In fact, glibc is calling 'tabort' before every syscalls, thus, any sysca=
ll
quoted hunk ↗ jump to hunk
called through glibc from inside a transaction will be doomed anyhow.
=20
This patch updates the test case to not assume that a syscall inside a
active transaction will succeed, because it will not anymore.
=20
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 tools/testing/selftests/powerpc/tm/tm-syscall.c | 6 ------
 1 file changed, 6 deletions(-)
=20
diff --git a/tools/testing/selftests/powerpc/tm/tm-syscall.c
b/tools/testing/selftests/powerpc/tm/tm-syscall.c
index 454b965a2db3..1439a87eba3a 100644
--- a/tools/testing/selftests/powerpc/tm/tm-syscall.c
+++ b/tools/testing/selftests/powerpc/tm/tm-syscall.c
@@ -78,12 +78,6 @@ int tm_syscall(void)
 	timeradd(&end, &now, &end);
=20
 	for (count =3D 0; timercmp(&now, &end, <); count++) {
-		/*
-		 * Test a syscall within a suspended transaction and verify
-		 * that it succeeds.
-		 */
-		FAIL_IF(getppid_tm(true) =3D=3D -1); /* Should succeed. */
-
 		/*
 		 * Test a syscall within an active transaction and verify that
 		 * it fails with the correct failure code.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help