All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki Poulose <suzuki@in.ibm.com>
To: renxiu liang <renxiu.liang@windriver.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [Patch] Fix mtest06 failure: caught unexpected signal - 11 --- exiting
Date: Sun, 19 Sep 2010 12:47:24 +0530	[thread overview]
Message-ID: <4C95B904.3070404@in.ibm.com> (raw)
In-Reply-To: <4C95B7D9.5060801@in.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]

Here is a patch which I had, sometime back. It is on an older version of 
LTP.

Cheers

Suzuki


, Suzuki Poulose wrote:
> , renxiu liang wrote:
>> On Sun, 2010-09-19 at 12:06 +0530, Suzuki Poulose wrote:
>>> Hello Renxiu,
>>>
>>> Sorry for the late reply. Could you please resend the patch ? I don't
>>> find the patch in the e-mail.
>>>
>> Hi Suzuki
>>
>> attached failure logs on different archs and patch for you.
>
> I don't understand why there should be ACCERR. The mmap is done with
> PROT_WRIT|PROT_READ. Could we get more info on which condition triggers
> this ?
>
> You may use GDB to break for the ACCERR case and take a look at the
> instruction which triggers this.
>
> Coming back to your patch :
>
> I think we should ensure the si_addr is within the map. (map_address,
> map_address+mapsize-1) ? We should not let the other SIGSEGVs go through.
>
> It may be like :
>
> case SIGSEGV:
> if ((si_addr >= map_address) &&
> (si_addr < (map_address + map_size) ) {
> ...
> ..
> }
>
>
> Thanks
>
> Suzuki
>
>
>
>
>>
>> thanks for help review this.
>>
>> BR
>> Renxiu
>>> Thanks
>>>
>>> Suzuki
>>> , renxiu liang wrote:
>>>> On Wed, 2010-09-01 at 00:27 -0700, Garrett Cooper wrote:
>>>>> On Wed, Sep 1, 2010 at 12:26 AM, Garrett Cooper<yanegomi@gmail.com>
>>>>> wrote:
>>>>>> On Mon, Aug 30, 2010 at 6:51 PM, renxiu liang
>>>>>> <renxiu.liang@windriver.com> wrote:
>>>>>>> On Wed, 2010-08-25 at 20:36 -0700, Garrett Cooper wrote:
>>>>>>>> On Wed, Aug 18, 2010 at 12:33 AM, renxiu liang
>>>>>>>> <renxiu.liang@windriver.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> We met the mtest06 failure several times; this is because in
>>>>>>>>> mtest06/mmap1.c, when handling the signal 11 in sig_handler, it
>>>>>>>>> doesn't
>>>>>>>>> cover another two race conditions:
>>>>>>>>> one is si_code equals "SEGV_MAPERR" but si_address does not
>>>>>>>>> equal to
>>>>>>>>> map_address; and one is si_code equals to "SEGV_ACCERR";
>>>>>>>>>
>>>>>>>>> see below error log:
>>>>>>>>>
>>>>>>>>> <<<test_start>>>
>>>>>>>>> tag=mtest06 stime=1270902396
>>>>>>>>> cmdline=" mmap1 -x 0.05"
>>>>>>>>> contacts=""
>>>>>>>>> analysis=exit
>>>>>>>>> initiation_status="ok"
>>>>>>>>> <<<test_output>>>
>>>>>>>>> mmap1 0 INFO : pid[5456]: map, change contents, unmap files
>>>>>>>>> 1000 times
>>>>>>>>> mmap1 0 INFO : created thread[1216369840]
>>>>>>>>> mmap1 0 INFO : pid[5456] - read contents of memory 0x48002000
>>>>>>>>> 1000 times
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> ......
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> mmap1 0 INFO : page fault occurred at 0x48002000
>>>>>>>>> caught unexpected signal - 11 --- exiting
>>>>>>>>> <<<execution_status>>>
>>>>>>>>> duration=1 termination_type=exited termination_id=255 corefile=no
>>>>>>>>> cutime=0 cstime=4
>>>>>>>>> <<<test_end>>>
>>>>>>>>>
>>>>>>>>> I made a patch to cover all the three race conditions in one
>>>>>>>>> case in
>>>>>>>>> sig_handler(),
>>>>>>>>> then run mtest06 repeatedly on different archs, test will not
>>>>>>>>> fail by
>>>>>>>>> catching signal 11.
>>>>>>>>
>>>>>>>> Could you print out what the value of info->si_code and
>>>>>>>> info->si_addr
>>>>>>>> are at the time of the fault? Also, which architecture(s) are you
>>>>>>>> running into this issue on?
>>>>>>> Hi Garrett,
>>>>>>>
>>>>>>> Sorry for the late reply; See attached mtest06 logs, I printed
>>>>>>> out the
>>>>>>> values of si_code, si_addr, map_address;
>>>>>>> it is reproducible on arm, x86, ppc and mips; though it is not
>>>>>>> reproducible every time, but can be reproducible if run the case
>>>>>>> repeatedly.
>>>>>>
>>>>>> Nothing is jumping out at me as being incorrect, so I think it's best
>>>>>> that I bring in a better pair of eyes, just in case.
>>>>>>
>>>>>> Suzuki-san,
>>>>>> Could you please help review this patch?
>>>>>
>>>> Hi Garrett,
>>>> No reply from Suzuki-san after almost three weeks; I'm afraid
>>>> Suzuki-san
>>>> didn't catch the mail, could you find someone else to review the patch?
>>>> thanks!
>>>>
>>>> BR,
>>>> Renxiu
>>>>
>>>>> CCing Suzuki-san...
>>>>> -Garrett
>>>>
>>>
>>
>


[-- Attachment #2: mtest06-mmap1.diff --]
[-- Type: text/plain, Size: 1818 bytes --]

diff -Naur ltp-full-20091231.orig/testcases/kernel/mem/mtest06/mmap1.c ltp-full-20091231/testcases/kernel/mem/mtest06/mmap1.c
--- ltp-full-20091231.orig/testcases/kernel/mem/mtest06/mmap1.c	2009-10-13 19:30:46.000000000 +0530
+++ ltp-full-20091231/testcases/kernel/mem/mtest06/mmap1.c	2010-03-15 16:30:33.000000000 +0530
@@ -138,6 +138,7 @@
 int 	   verbose_print = FALSE;/* when called with -v print more info       */
 caddr_t    *map_address;	/* address of the file mapped.	              */
 sigjmp_buf jmpbuf;		/* argument to sigsetjmp and siglongjmp       */
+long	   map_len;
 
 char *TCID = "mmap1";
 int TST_TOTAL = 1;
@@ -168,14 +169,22 @@
              _exit(0);
 
         case SIGSEGV:
-             if (info->si_code == SEGV_MAPERR &&
-                      info->si_addr == map_address)
+             if ( info->si_addr == map_address ||
+		 (map_address && (info->si_addr >= (void*) map_address &&
+				 info->si_addr < (void *)((long)map_address + map_len))
+		  )
+		)
              {
                   tst_resm(TINFO,
                     "page fault occurred at %p",
                     map_address);
                   longjmp(jmpbuf, 1);
-             }
+             } else {
+            	  fprintf(stderr, "caught SIGSEGV at %p while mmap is (%p,%p) -  exiting\n",
+				info->si_addr, map_address, (void*)((long)map_address + map_len));
+		  _exit(-1);
+	     }
+		
         default:
             fprintf(stderr, "caught unexpected signal - %d --- exiting\n",
                      signal);
@@ -293,6 +302,9 @@
 		       (long *)args;
     long exit_val = 0;  /* exit value of the pthread		      */
 
+    /* The size of the map */
+    map_len = mwuargs[1];
+
     tst_resm(TINFO, "pid[%d]: map, change contents, unmap files %d times",
 		getpid(), (int)mwuargs[2]);
     if (verbose_print)

[-- Attachment #3: Type: text/plain, Size: 276 bytes --]

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

  parent reply	other threads:[~2010-09-19  7:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-18  7:33 [LTP] [Patch] Fix mtest06 failure: caught unexpected signal - 11 --- exiting renxiu liang
2010-08-18  8:35 ` Garrett Cooper
2010-08-26  3:36 ` Garrett Cooper
2010-08-31  1:51   ` renxiu liang
2010-09-01  7:26     ` Garrett Cooper
2010-09-01  7:27       ` Garrett Cooper
     [not found]         ` <1284874992.12271.5.camel@PEK-RLIANG-D1>
     [not found]           ` <4C95AF8A.8000803@in.ibm.com>
     [not found]             ` <1284878205.12271.9.camel@PEK-RLIANG-D1>
     [not found]               ` <4C95B7D9.5060801@in.ibm.com>
2010-09-19  7:17                 ` Suzuki Poulose [this message]
2010-09-25  3:43                   ` renxiu liang
  -- strict thread matches above, loose matches on Subject: below --
2010-09-06 16:16 Subrata Modak
     [not found] <52CF90264091A14888078A031D780F4305936FA4@ism-mail03.corp.ad.wrs.com>
2010-08-17  5:57 ` Liang, RenXiu
2010-09-06 16:17   ` Subrata Modak

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=4C95B904.3070404@in.ibm.com \
    --to=suzuki@in.ibm.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=renxiu.liang@windriver.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.