syscalls/signal06: fix test for regression with earlier version of gcc and kernel

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

        while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

Quoted 8 lines · Guangwen Feng

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

        while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

Sounds reasonable! To verify that I did disassemble work of the pre/post signal06 for comparison:

signal06 old version
-------------------------
void test(double d)

{
        int loop = 0;
        int pid = getpid();

402846: 89 c7 mov %eax,%edi

        D = d;
  402848:       f2 0f 11 05 b0 27 21    movsd  %xmm0,0x2127b0(%rip)
    # 615000 <D>
  40284f:       00
        while (D == d && loop < LOOPS) {
  402850:       f2 0f 10 05 a8 27 21    movsd  0x2127a8(%rip),%xmm0
    # 615000 <D>
  402857:       00
  402858:       66 0f 2e 44 24 08       ucomisd 0x8(%rsp),%xmm0
  40285e:       0f 85 b8 00 00 00       jne    40291c <test+0xec>
  402864:       0f 8a b2 00 00 00       jp     40291c <test+0xec>
  40286a:       31 db                   xor    %ebx,%ebx
  40286c:       ba c8 00 00 00          mov    $0xc8,%edx
  402871:       be 01 00 00 00          mov    $0x1,%esi
  402876:       eb 0a                   jmp    402882 <test+0x52>
  402878:       81 fb 10 27 00 00       cmp    $0x2710,%ebx
  40287e:       66 90                   xchg   %ax,%ax
  402880:       74 6d                   je     4028ef <test+0xbf>

after applying this patch
------------------------------
void test(void)

{
        int loop = 0;
  402c58:       bb 00 00 00 00          mov    $0x0,%ebx
        int pid = getpid();

        D = VALUE;
        while (D == VALUE && loop < LOOPS) {
  402c5d:       0f 85 b5 00 00 00       jne    402d18 <test+0xe8>
  402c63:       89 c7                   mov    %eax,%edi
                /* sys_tkill(pid, SIGHUP); asm to avoid save/reload
                 * fp regs around c call */
                asm ("" : : "a"(__NR_tkill), "D"(pid), "S"(SIGHUP));
  402c65:       ba c8 00 00 00          mov    $0xc8,%edx
  402c6a:       be 01 00 00 00          mov    $0x1,%esi
{
        int loop = 0;
        int pid = getpid();

        D = VALUE;
        while (D == VALUE && loop < LOOPS) {
  402c6f:       66 0f 28 d1             movapd %xmm1,%xmm2
  402c73:       eb 11                   jmp    402c86 <test+0x56>
  402c75:       0f 1f 00                nopl   (%rax)
  402c78:       66 0f 2e c2             ucomisd %xmm2,%xmm0
  402c7c:       75 1d                   jne    402c9b <test+0x6b>
  402c7e:       81 fb a0 86 01 00       cmp    $0x186a0,%ebx
  402c84:       74 65                   je     402ceb <test+0xbb>

Quoted 7 lines

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

This is also acceptable, seems too many signals more than one kenel can handled that easily cause segmental fault at the moment.

I test this patch on RHEL5.11(reproduced) and RHEL7.2(pass), it works fine.

Regards,
Li Wang

.

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

	while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

Signed-off-by Guangwen Feng <[email protected]>

---
 testcases/kernel/syscalls/signal/signal06.c | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

testcases/kernel/syscalls/signal/signal06.c +17 -12

index 75ef733..81fd138 100644
@@ -31,8 +31,8 @@
  * 		Date:   Tue Sep 2 19:57:17 2014 +0200
  *
  *      commit 66463db4fc5605d51c7bb81d009d5bf30a783a2c
- *               Author: Oleg Nesterov <[email protected]>
- *               Date:   Tue Sep 2 19:57:13 2014 +0200
+ *              Author: Oleg Nesterov <[email protected]>
+ *              Date:   Tue Sep 2 19:57:13 2014 +0200
  *
  * Reproduce:
  *	Test-case (needs -O2).

@@ -55,20 +55,21 @@ int TST_TOTAL = 5;
 
 #if __x86_64__
 
-#define LOOPS 10000
+#define LOOPS 100000
+#define VALUE 123.456
 
 volatile double D;
 volatile int FLAGE;
 
 char altstack[4096 * 10] __attribute__((aligned(4096)));
 
-void test(double d)
+void test(void)
 {
 	int loop = 0;
 	int pid = getpid();
 
-	D = d;
-	while (D == d && loop < LOOPS) {
+	D = VALUE;
+	while (D == VALUE && loop < LOOPS) {
 		/* sys_tkill(pid, SIGHUP); asm to avoid save/reload
 		 * fp regs around c call */
 		asm ("" : : "a"(__NR_tkill), "D"(pid), "S"(SIGHUP));

@@ -94,12 +95,16 @@ void sigh(int sig LTP_ATTRIBUTE_UNUSED)
 
 void *tfunc(void *arg LTP_ATTRIBUTE_UNUSED)
 {
-	for (; ;) {
-		TEST(mprotect(altstack, sizeof(altstack), PROT_READ));
-		if (TEST_RETURN == -1)
-			tst_brkm(TBROK | TTERRNO, NULL, "mprotect failed");
+	int i;
+
+	for (i = -1; ; i *= -1) {
+		if (i == -1) {
+			TEST(mprotect(altstack, sizeof(altstack), PROT_READ));
+			if (TEST_RETURN == -1)
+				tst_brkm(TBROK | TTERRNO, NULL, "mprotect failed");
+		}
 
-		TEST(mprotect(altstack, sizeof(altstack), PROT_READ|PROT_WRITE));
+		TEST(mprotect(altstack, sizeof(altstack), PROT_READ | PROT_WRITE));
 		if (TEST_RETURN == -1)
 			tst_brkm(TBROK | TTERRNO, NULL, "mprotect failed");
 

@@ -148,7 +153,7 @@ int main(int ac, char **av)
 				tst_brkm(TBROK | TRERRNO, NULL,
 						"pthread_create failed");
 
-			test(123.456);
+			test();
 
 			TEST(pthread_join(pt, NULL));
 			if (TEST_RETURN)

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

	while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

Hi!
First of all sorry for the delay.

Quoted 8 lines

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

	while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

This looks OK.

Quoted 6 lines

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

Hmm, what is the exact problem here? Does the old kernel break if we send the signal too fast?

I do not like much that the test takes ten times more time to finish now.

Quoted 2 lines

Hmm, what is the exact problem here? Does the old kernel break if we send the signal too fast?

Yes, running signal06 reports segmentation fault and breaks the test if we send the signal too fast on the old kernel.

Quoted 2 lines

I do not like much that the test takes ten times more time to finish now.

Yes, it will take ten times more time than before, but it only takes 3~4 seconds to finish...

By current LOOPS(10000), most of the time, the buggy kernel can be reproduced, but there is still a chance(about 0.5% in my environment) to miss.

Hi!

Quoted 5 lines

Quoted 2 lines

Hmm, what is the exact problem here? Does the old kernel break if we send the signal too fast?

Yes, running signal06 reports segmentation fault and breaks the test if we send the signal too fast on the old kernel.

Hmm, that sounds like a bug itself since we set signal handler for the SIGSEGV, it shouldn't kill the process while we try to write to the read only memory. Can you try to run it in a debugger and send a trace?

Since what we do is disable/enable write access to the alternative while simoutaneously hammer the process with SIGHUP in order to trigger segfault inside of the sighup signal handler.

I wonder why we have to do that asynchronously in the first place, if there is a need to hit a particular spot in the kernel while the signal stack is being written.

Anyway on which systems is this bug reproducible? I can try to make it both reliable and fast.

Quoted 6 lines

Quoted 3 lines

I do not like much that the test takes ten times more time to finish now.

Yes, it will take ten times more time than before, but it only takes 3~4 seconds to finish...

Let me put that in perspective. We have more than 3000 tests in LTP, if each of these would take just a few seconds more, the test run would take a few more hours to finish.

And there is a reason why we need the LTP run to be as fast as possible. The longer the run takes the less people would use it and it would be used less frequently which would make all the work put into these testcases less valuable.

All in all I'm mildly opposed to each change that increses the runtime if it's not absolutely necessary.

Quoted 3 lines

By current LOOPS(10000), most of the time, the buggy kernel can be reproduced, but there is still a chance(about 0.5% in my environment) to miss.

Hmm, what about increasing it twice or four times? What is the probability of missing the bug then?

Yes, I guess this is the kernel's bug, but sorry I didn't look into the real reason of the segfault issue much.

[root@RHEL5U11ga_Intel64 signal]# gdb ./signal06 core.18623
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-45.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/ltp/testcases/kernel/syscalls/signal/signal06...done. [New Thread 18623]
[New Thread 18625]
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffe3384000 Core was generated by `./signal06'.
Program terminated with signal 11, Segmentation fault.
#0 test (d=123.456) at signal06.c:71
71 while (D == d && loop < LOOPS) {
(gdb) bt
#0 test (d=123.456) at signal06.c:71
#1 0x0000000000402bb7 in main (ac=<value optimized out>, av=<value optimized out>) at signal06.c:151

Quoted 4 lines

Quoted 3 lines

By current LOOPS(10000), most of the time, the buggy kernel can be reproduced, but there is still a chance(about 0.5% in my environment) to miss.

Quoted 3 lines

Hmm, what about increasing it twice or four times? What is the probability of missing the bug then?

2 times(20000 loops): 99.9% reproducible
4 times(40000 loops): 100% reproducible

Is it acceptable to increase it four times?

Hi!

Quoted 24 lines

Yes, I guess this is the kernel's bug, but sorry I didn't look into the real reason of the segfault issue much.

[root@RHEL5U11ga_Intel64 signal]# gdb ./signal06 core.18623
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-45.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/ltp/testcases/kernel/syscalls/signal/signal06...done. [New Thread 18623]
[New Thread 18625]
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2

Quoted 8 lines

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffe3384000 Core was generated by `./signal06'.
Program terminated with signal 11, Segmentation fault.
#0 test (d=123.456) at signal06.c:71
71 while (D == d && loop < LOOPS) {
(gdb) bt
#0 test (d=123.456) at signal06.c:71
#1 0x0000000000402bb7 in main (ac=<value optimized out>, av=<value optimized out>) at signal06.c:151

So it segfaults in the test() function, we aren't doing anything wrong there. So this really looks like a bug itself.

Supposedly this causes the test segfault on a system where the original bug cannot be reproduced, right?

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

By current LOOPS(10000), most of the time, the buggy kernel can be reproduced, but there is still a chance(about 0.5% in my environment) to miss.

Hmm, what about increasing it twice or four times? What is the probability of missing the bug then?

Quoted 4 lines

2 times(20000 loops): 99.9% reproducible
4 times(40000 loops): 100% reproducible

Is it acceptable to increase it four times?

That is 2.5 times better :)

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

	while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

Signed-off-by Guangwen Feng <[email protected]>

---
 testcases/kernel/syscalls/signal/signal06.c | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

testcases/kernel/syscalls/signal/signal06.c +17 -12

index 75ef733..1f1b31c 100644
@@ -31,8 +31,8 @@
  * 		Date:   Tue Sep 2 19:57:17 2014 +0200
  *
  *      commit 66463db4fc5605d51c7bb81d009d5bf30a783a2c
- *               Author: Oleg Nesterov <[email protected]>
- *               Date:   Tue Sep 2 19:57:13 2014 +0200
+ *              Author: Oleg Nesterov <[email protected]>
+ *              Date:   Tue Sep 2 19:57:13 2014 +0200
  *
  * Reproduce:
  *	Test-case (needs -O2).

@@ -55,20 +55,21 @@ int TST_TOTAL = 5;
 
 #if __x86_64__
 
-#define LOOPS 10000
+#define LOOPS 30000
+#define VALUE 123.456
 
 volatile double D;
 volatile int FLAGE;
 
 char altstack[4096 * 10] __attribute__((aligned(4096)));
 
-void test(double d)
+void test(void)
 {
 	int loop = 0;
 	int pid = getpid();
 
-	D = d;
-	while (D == d && loop < LOOPS) {
+	D = VALUE;
+	while (D == VALUE && loop < LOOPS) {
 		/* sys_tkill(pid, SIGHUP); asm to avoid save/reload
 		 * fp regs around c call */
 		asm ("" : : "a"(__NR_tkill), "D"(pid), "S"(SIGHUP));

@@ -94,12 +95,16 @@ void sigh(int sig LTP_ATTRIBUTE_UNUSED)
 
 void *tfunc(void *arg LTP_ATTRIBUTE_UNUSED)
 {
-	for (; ;) {
-		TEST(mprotect(altstack, sizeof(altstack), PROT_READ));
-		if (TEST_RETURN == -1)
-			tst_brkm(TBROK | TTERRNO, NULL, "mprotect failed");
+	int i;
+
+	for (i = -1; ; i *= -1) {
+		if (i == -1) {
+			TEST(mprotect(altstack, sizeof(altstack), PROT_READ));
+			if (TEST_RETURN == -1)
+				tst_brkm(TBROK | TTERRNO, NULL, "mprotect failed");
+		}
 
-		TEST(mprotect(altstack, sizeof(altstack), PROT_READ|PROT_WRITE));
+		TEST(mprotect(altstack, sizeof(altstack), PROT_READ | PROT_WRITE));
 		if (TEST_RETURN == -1)
 			tst_brkm(TBROK | TTERRNO, NULL, "mprotect failed");
 

@@ -148,7 +153,7 @@ int main(int ac, char **av)
 				tst_brkm(TBROK | TRERRNO, NULL,
 						"pthread_create failed");
 
-			test(123.456);
+			test();
 
 			TEST(pthread_join(pt, NULL));
 			if (TEST_RETURN)

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

	while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

Hi!

Quoted 9 lines

1. Currently, following code is incorrect on some releases with earlier version of gcc(tested on RHEL5.11GA):

	while (D == d && loop < LOOPS) {

Because the argument in function test(double d) is used via (%rsp), but here we actually need a xmm register to trigger the fpu bug. So use global value instead to make sure to take use of xmm.

Quoted 6 lines

2. Although this regression test is designed to trigger SIGSEGV intentionally, on some releases with old kernel(tested on RHEL5.11GA), this will still lead to segmentation fault that terminate the program and break the test even though compiling with -O2. So slightly adjust the weight of the codes in child thread to depress SIGSEGV trigger's chance while increase LOOPS to ensure reproducible.

This needs to be worded a bit better, I had to read the email discussion to remember what we are trying to avoid here.

Something as:

2. Although this regresssion test is designed to trigger SIGSEGV intentionally in order to invoke signal handler, producing it too fast can lead to a program termination on older kernels (found in RHEL5.11GA). Hence we divide the frequency in half and increase number of LOOPS at the same time as a compensation to make sure that the bug is 100% reproducible.

OK to commit with this change to the patch description?