Re: [LTP] [PATCH 1/1] openposix_mmap_11_4

[Michal Simek <michal.simek@petalogix.com>]

Hi,
> On Sat, 2009-07-18 at 12:28 -0700, Garrett Cooper wrote:
>   
>> On Thu, Jul 16, 2009 at 11:37 PM, hefan<fhe@novell.com> wrote:
>>     
>>> hi,
>>>
>>> *[Patch 1/1] Patch for fixing the failed testcase openposix_mmap_11_4
>>>
>>> -modified the file
>>> *testcases/open_posix_testsuite/conformance/interfaces/mmap/11-4.c
>>>       
First of all - this is really small explanation why you are fixing this
issue. After some month
none will know why you did this change.


>>>
>>> Signed-off-by:  fredrick he <fhe@novell.com>
>>>
>>> ---
>>> ltp.orig/testcases/open_posix_testsuite/conformance/interfaces/mmap/11-4.c      2009-07-17 11:53:36.000000000 +0800
>>> +++
>>> ltp/testcases/open_posix_testsuite/conformance/interfaces/mmap/11-4.c
>>> 2009-07-17 11:57:09.000000000 +0800
>>> @@ -130,7 +130,9 @@ int main()
>>>   flag = MAP_SHARED;
>>>   off = 0;
>>>   pa = mmap(addr, len, prot, flag, fd_2, off);
>>> -  pa_2 = mmap(addr, len, prot, flag, fd_2, off);
>>> +  addr = pa;
>>> +  memset(addr,0,len*2);
>>> +  pa_2 = mmap(addr, len, prot, flag|MAP_FIXED, fd_2, off);
>>>   if (pa_2 == MAP_FAILED)
>>>   {
>>>     printf("Test FAIL: " TNAME " Error at 2nd mmap(): %s\n",
>>>       
>> Hi Fan,
>>     Some questions / observations:
>>
>> 1. Yes, the testcases does fail on my machine today.
>> 2. Yes, doing what you say above does work (at least the testcase passes).
>> 3. Are you positive that your set of steps above in fact don't
>> invalidate the purpose of the testcase, by accident, in particular the
>> memset call? I ask because of the following statement in the mmap
>> manpage:
>>
>>        If addr is NULL, then the kernel chooses the address at which to create
>>        the mapping; this is the most portable method of creating  a  new  map-
>>        ping.   If  addr  is not NULL, then the kernel takes it as a hint about
>>        where to place the mapping; on Linux, the mapping will be created at  a
>>        nearby  page  boundary.   The address of the new mapping is returned as
>>        the result of the call.
>>
>> What you're in effect doing is changing the 2nd mmap call from an
>> arbitrary address to a set virtual address at 0x0. Is that indeed
>> correct?
>>     
> in this case, the situation is like this, we create a new file about 512
> bytes and mmap it into the mem, then we modify one byte besides the 512
> bytes address, and munmap it. and in the father process remmap it back
> to check whether the one more byte is write back to the files.
>
> i have checked that when finished munmap and close the file in the child
> process, the file didn't contain the 513th byte, the size of this file
> is right 512 bytes.but in this case after the second mmap finished, the
> 513th byte does appear again. it's a conflict. 
>
> in my opinion this is because of the compiler or some optimizations. so
> i think the memory should to be memset before mmap and it does work.
>   
If is the problem with compiler/optimization means that tests is ok -
the problem is with your
compiler not with code.
This need more investigations to find out where the problem is.

Michal

>   
>> 4. Have you talked to the openposix test suite folks about this yet?
>>     
> no,i have no idea on how to talk to the openposix and i do want to talk
> to them :) can you give me some suggestions about this? thx~
>
>   
>> 5. FWIW the same results are seen on FreeBSD, so I don't doubt that
>> the testcase is broken -- I just want to ensure that it's fixed in the
>> proper way :)...
>>     
> as mentioned above 
>
>   
>> [gcooper@optimus /scratch/open_posix_testsuite]$
>> conformance/interfaces/mmap/11-4.test
>> pa: 0x800537000
>> pa_2: 0x800537000
>> Test Fail: mmap/11-4.c Modification of the partial page at the end of
>> an object is written out
>> [gcooper@optimus /scratch/open_posix_testsuite]$ uname -a
>> FreeBSD optimus.zenmetsuhitotuyaneshita.net 8.0-CURRENT FreeBSD
>> 8.0-CURRENT #0: Sun Jul  5 14:43:07 PDT 2009
>> root@optimus.zenmetsuhitotuyaneshita.net:/usr/obj/usr/src/sys/OPTIMUS
>> amd64
>>
>> Thanks,
>> -Garrett
>>     
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>   


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list