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