[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[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.

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 <fenggw-fnst@cn.fujitsu.com>
---
 testcases/kernel/syscalls/signal/signal06.c | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/testcases/kernel/syscalls/signal/signal06.c b/testcases/kernel/syscalls/signal/signal06.c
index 75ef733..81fd138 100644
--- a/testcases/kernel/syscalls/signal/signal06.c
+++ b/testcases/kernel/syscalls/signal/signal06.c
@@ -31,8 +31,8 @@
  * 		Date:   Tue Sep 2 19:57:17 2014 +0200
  *
  *      commit 66463db4fc5605d51c7bb81d009d5bf30a783a2c
- *               Author: Oleg Nesterov <oleg@redhat.com>
- *               Date:   Tue Sep 2 19:57:13 2014 +0200
+ *              Author: Oleg Nesterov <oleg@redhat.com>
+ *              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.8.4.2

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Li Wang]

On 5 August 2016 at 14:58, Guangwen Feng <fenggw-fnst@cn.fujitsu.com> wrote:
> 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>


>
> 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

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng]

Hi!

Thanks for your review and confirmation!

Regards,
Guangwen Feng

On 08/08/2016 04:44 PM, Li Wang wrote:
> On 5 August 2016 at 14:58, Guangwen Feng <fenggw-fnst@cn.fujitsu.com> wrote:
>> 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>
> 
> 
>>
>> 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
> 
> 
> .
> 

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng]

Hi!

Ping, thanks!


Regards,
Guangwen Feng

On 08/05/2016 02:58 PM, Guangwen Feng wrote:
> 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 <fenggw-fnst@cn.fujitsu.com>
> ---
>  testcases/kernel/syscalls/signal/signal06.c | 29 +++++++++++++++++------------
>  1 file changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git a/testcases/kernel/syscalls/signal/signal06.c b/testcases/kernel/syscalls/signal/signal06.c
> index 75ef733..81fd138 100644
> --- a/testcases/kernel/syscalls/signal/signal06.c
> +++ b/testcases/kernel/syscalls/signal/signal06.c
> @@ -31,8 +31,8 @@
>   * 		Date:   Tue Sep 2 19:57:17 2014 +0200
>   *
>   *      commit 66463db4fc5605d51c7bb81d009d5bf30a783a2c
> - *               Author: Oleg Nesterov <oleg@redhat.com>
> - *               Date:   Tue Sep 2 19:57:13 2014 +0200
> + *              Author: Oleg Nesterov <oleg@redhat.com>
> + *              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)
> 

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Cyril Hrubis]

Hi!
First of all sorry for the delay.

> 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.

> 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.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng]

Hi!

Thanks for your comments!

On 10/05/2016 09:43 PM, Cyril Hrubis wrote:
> Hi!
> First of all sorry for the delay.
> 
>> 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.
> 
>> 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?

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

> 
> 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.


Best Regards,
Guangwen Feng

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Cyril Hrubis]

Hi!
> > 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.

> > 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.

> 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?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng]

Hi!

On 10/06/2016 07:15 PM, Cyril Hrubis wrote:
> Hi!
>>> 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?

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)@signal06.c:71
#1  0x0000000000402bb7 in main (ac=<value optimized out>, av=<value optimized out>) at signal06.c:151

(gdb) disassemble 
Dump of assembler code for function test:
0x0000000000402910 <test+0>:	push   %rbx
0x0000000000402911 <test+1>:	sub    $0x10,%rsp
0x0000000000402915 <test+5>:	movsd  %xmm0,0x8(%rsp)
0x000000000040291b <test+11>:	callq  0x402278 <getpid@plt>
0x0000000000402920 <test+16>:	movsd  0x8(%rsp),%xmm0
0x0000000000402926 <test+22>:	mov    %eax,%edi
0x0000000000402928 <test+24>:	movsd  %xmm0,0x2136d0(%rip)        # 0x616000 <D>
0x0000000000402930 <test+32>:	movsd  0x2136c8(%rip),%xmm0        # 0x616000 <D>
0x0000000000402938 <test+40>:	ucomisd 0x8(%rsp),%xmm0
0x000000000040293e <test+46>:	jne    0x4029fc <test+236>
0x0000000000402944 <test+52>:	jp     0x4029fc <test+236>
0x000000000040294a <test+58>:	xor    %ebx,%ebx
0x000000000040294c <test+60>:	mov    $0xc8,%edx
0x0000000000402951 <test+65>:	mov    $0x1,%esi
0x0000000000402956 <test+70>:	jmp    0x402962 <test+82>
0x0000000000402958 <test+72>:	cmp    $0x2710,%ebx
0x000000000040295e <test+78>:	xchg   %ax,%ax
0x0000000000402960 <test+80>:	je     0x4029cf <test+191>
0x0000000000402962 <test+82>:	mov    %edx,%eax
0x0000000000402964 <test+84>:	syscall 
0x0000000000402966 <test+86>:	movsd  0x213692(%rip),%xmm0        # 0x616000 <D>
0x000000000040296e <test+94>:	add    $0x1,%ebx
0x0000000000402971 <test+97>:	ucomisd 0x8(%rsp),%xmm0
0x0000000000402977 <test+103>:	jp     0x40297b <test+107>
0x0000000000402979 <test+105>:	je     0x402958 <test+72>
0x000000000040297b <test+107>:	xor    %eax,%eax
0x000000000040297d <test+109>:	mov    %ebx,%r8d
0x0000000000402980 <test+112>:	mov    $0x40b2cb,%ecx
0x0000000000402985 <test+117>:	mov    $0x10,%edx
0x000000000040298a <test+122>:	mov    $0x51,%esi
0x000000000040298f <test+127>:	mov    $0x40b2c0,%edi
0x0000000000402994 <test+132>:	movl   $0x1,0x21e662(%rip)        # 0x621000 <FLAGE>
0x000000000040299e <test+142>:	callq  0x4043d0 <tst_resm_>
0x00000000004029a3 <test+147>:	cmp    $0x2710,%ebx
0x00000000004029a9 <test+153>:	jne    0x402a24 <test+276>
0x00000000004029ab <test+155>:	mov    0x20ec16(%rip),%r8        # 0x6115c8 <TCID>
0x00000000004029b2 <test+162>:	add    $0x10,%rsp
0x00000000004029b6 <test+166>:	mov    $0x40b2d5,%ecx
0x00000000004029bb <test+171>:	pop    %rbx
0x00000000004029bc <test+172>:	xor    %edx,%edx
0x00000000004029be <test+174>:	mov    $0x54,%esi
0x00000000004029c3 <test+179>:	mov    $0x40b2c0,%edi
0x00000000004029c8 <test+184>:	xor    %eax,%eax
0x00000000004029ca <test+186>:	jmpq   0x4043d0 <tst_resm_>
0x00000000004029cf <test+191>:	mov    $0x2710,%r8d
0x00000000004029d5 <test+197>:	mov    $0x40b2cb,%ecx
0x00000000004029da <test+202>:	mov    $0x10,%edx
0x00000000004029df <test+207>:	mov    $0x51,%esi
0x00000000004029e4 <test+212>:	mov    $0x40b2c0,%edi
0x00000000004029e9 <test+217>:	xor    %eax,%eax
0x00000000004029eb <test+219>:	movl   $0x1,0x21e60b(%rip)        # 0x621000 <FLAGE>
0x00000000004029f5 <test+229>:	callq  0x4043d0 <tst_resm_>
0x00000000004029fa <test+234>:	jmp    0x4029ab <test+155>
0x00000000004029fc <test+236>:	xor    %r8d,%r8d
0x00000000004029ff <test+239>:	mov    $0x40b2cb,%ecx
0x0000000000402a04 <test+244>:	mov    $0x10,%edx
0x0000000000402a09 <test+249>:	mov    $0x51,%esi
0x0000000000402a0e <test+254>:	mov    $0x40b2c0,%edi
0x0000000000402a13 <test+259>:	xor    %eax,%eax
0x0000000000402a15 <test+261>:	movl   $0x1,0x21e5e1(%rip)        # 0x621000 <FLAGE>
0x0000000000402a1f <test+271>:	callq  0x4043d0 <tst_resm_>
0x0000000000402a24 <test+276>:	mov    $0x40b2e7,%ecx
0x0000000000402a29 <test+281>:	mov    $0x1,%edx
0x0000000000402a2e <test+286>:	mov    $0x56,%esi
0x0000000000402a33 <test+291>:	mov    $0x40b2c0,%edi
0x0000000000402a38 <test+296>:	xor    %eax,%eax
0x0000000000402a3a <test+298>:	callq  0x4043d0 <tst_resm_>
0x0000000000402a3f <test+303>:	callq  0x404670 <tst_exit>
End of assembler dump.

> 
> 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.

Thanks very much.
The segfault issue can be reproduced steadily in RHEL5.11GA(2.6.18-398.el5).

> 
>>> 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.
> 

OK, I understand, will know for next time, thanks.

>> 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?
> 

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

Is it acceptable to increase it four times?


Best Regards,
Guangwen Feng

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Cyril Hrubis]

Hi!
> 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

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?

> >> 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?
> > 
> 
> 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 :)

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng]

Hi!

On 10/10/2016 09:15 PM, Cyril Hrubis wrote:
> Hi!
>> 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
> 
> 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?

Yes, the original bug should be reproduced by signal06 on this system.
but the segfault issue breaks the regression test.

> 
>>>> 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?
>>>
>>
>> 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 :)

So, may I just increase it to 4 times and send a v2?


Best Regards,
Guangwen Feng

[LTP] [PATCH v2] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[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.

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 <fenggw-fnst@cn.fujitsu.com>
---
 testcases/kernel/syscalls/signal/signal06.c | 29 +++++++++++++++++------------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/testcases/kernel/syscalls/signal/signal06.c b/testcases/kernel/syscalls/signal/signal06.c
index 75ef733..1f1b31c 100644
--- a/testcases/kernel/syscalls/signal/signal06.c
+++ b/testcases/kernel/syscalls/signal/signal06.c
@@ -31,8 +31,8 @@
  * 		Date:   Tue Sep 2 19:57:17 2014 +0200
  *
  *      commit 66463db4fc5605d51c7bb81d009d5bf30a783a2c
- *               Author: Oleg Nesterov <oleg@redhat.com>
- *               Date:   Tue Sep 2 19:57:13 2014 +0200
+ *              Author: Oleg Nesterov <oleg@redhat.com>
+ *              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.8.4.2

[LTP] [PATCH v2] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng]

Hi!

Ping, thanks!


Best Regards,
Guangwen Feng

On 11/16/2016 04:14 PM, Guangwen Feng wrote:
> 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 <fenggw-fnst@cn.fujitsu.com>
> ---
>  testcases/kernel/syscalls/signal/signal06.c | 29 +++++++++++++++++------------
>  1 file changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git a/testcases/kernel/syscalls/signal/signal06.c b/testcases/kernel/syscalls/signal/signal06.c
> index 75ef733..1f1b31c 100644
> --- a/testcases/kernel/syscalls/signal/signal06.c
> +++ b/testcases/kernel/syscalls/signal/signal06.c
> @@ -31,8 +31,8 @@
>   * 		Date:   Tue Sep 2 19:57:17 2014 +0200
>   *
>   *      commit 66463db4fc5605d51c7bb81d009d5bf30a783a2c
> - *               Author: Oleg Nesterov <oleg@redhat.com>
> - *               Date:   Tue Sep 2 19:57:13 2014 +0200
> + *              Author: Oleg Nesterov <oleg@redhat.com>
> + *              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)
> 

[LTP] [PATCH v2] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Cyril Hrubis]

Hi!
> 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.

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?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH v2] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Guangwen Feng]

Hi!

On 02/10/2017 12:19 AM, Cyril Hrubis wrote:
> Hi!
>> 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.
> 
> 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?

Sure, the description is much better now.
Thanks very much!

Best Regards,
Guangwen Feng

[LTP] [PATCH v2] syscalls/signal06: fix test for regression with earlier version of gcc and kernel

[Cyril Hrubis]

Hi!
Pushed, thanks.

-- 
Cyril Hrubis
chrubis@suse.cz