The Documentation/powerpc/transactional_memory.txt says:
"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."
With this new TM mechanism, the syscall will continue to be executed if the
syscall happens on a suspended syscall, but, the syscall will *fail* if the
transaction is still active during the syscall invocation.
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.
This new model will break part of this test, but I understand that that the
documentation above didn't guarantee that the syscall would succeed, and it
will never succeed anymore now on.
In fact, glibc is calling 'tabort' before every syscalls, thus, any syscall
called through glibc from inside a transaction will be doomed anyhow.
This patch updates the test case to not assume that a syscall inside a
active transaction will succeed, because it will not anymore.
Signed-off-by: Breno Leitao <lei...@debian.org>
---
tools/testing/selftests/powerpc/tm/tm-syscall.c | 6 ------
1 file changed, 6 deletions(-)
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);
for (count = 0; timercmp(&now, &end, <); count++) {
- /*
- * Test a syscall within a suspended transaction and verify
- * that it succeeds.
- */
- FAIL_IF(getppid_tm(true) == -1); /* Should succeed. */
-
/*
* Test a syscall within an active transaction and verify that
* it fails with the correct failure code.
--
2.19.0
