public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel
Date: Tue, 16 Aug 2016 11:08:52 +0800	[thread overview]
Message-ID: <57B283C4.5020903@cn.fujitsu.com> (raw)
In-Reply-To: <CAE1O6mgTj1WsRg1-UHpq32onixeKpo3xTbU6FiqDTK=jdE=uRw@mail.gmail.com>

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



  reply	other threads:[~2016-08-16  3:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-05  6:58 [LTP] [PATCH] syscalls/signal06: fix test for regression with earlier version of gcc and kernel Guangwen Feng
2016-08-08  8:44 ` Li Wang
2016-08-16  3:08   ` Guangwen Feng [this message]
2016-09-20  9:59 ` Guangwen Feng
2016-10-05 13:43 ` Cyril Hrubis
2016-10-06 10:31   ` Guangwen Feng
2016-10-06 11:15     ` Cyril Hrubis
2016-10-10  7:05       ` Guangwen Feng
2016-10-10 13:15         ` Cyril Hrubis
2016-10-11  7:17           ` Guangwen Feng
2016-11-16  8:14           ` [LTP] [PATCH v2] " Guangwen Feng
2017-02-09  9:00             ` Guangwen Feng
2017-02-09 16:19             ` Cyril Hrubis
2017-02-13  3:38               ` Guangwen Feng
2017-02-13  9:12                 ` Cyril Hrubis

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=57B283C4.5020903@cn.fujitsu.com \
    --to=fenggw-fnst@cn.fujitsu.com \
    --cc=ltp@lists.linux.it \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox