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

[Garrett Cooper <yanegomi@gmail.com>]

On Sun, Jul 19, 2009 at 10:54 PM, Michal
Simek<michal.simek@petalogix.com> wrote:
> 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.

Ok.

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

No, according to the manpage it'll map to the boundary of the closest
page size, in my opinion what might be occurring is the system is
either overallocating or underallocating, depending on the system page
size and what's being passed in for a length. What the page size is,
I'd surely like to know...

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

I wouldn't necessarily say that. Based on Frederick's explanation, it
sounds like someone fed in an inappropriate bound, or didn't NUL
terminate the boundary and just went off into uncharted territory
without first checking where they were `on the map'.

Based on my experience and recollection, this is legitimate in C
behavior as long as you're within the applications memory limits --
you've just entered the twilight zone between realities, where you're
beyond your address space, but not beyond the point of no return
(EACCES), where the kernel *should* terminate your userland app.

Whether or not that was the intention of the POSIX folks, is another
question indeed, as the documentation states (in the header of the .c
file):

 * Implementation performs mapping operations over whole pages.
 * Thus, while the argument len
 * need not meet a size or alignment constraint,
 * the implementation shall include, in any mapping
 * operation, any partial page specified by the range [pa,pa+len).
 * The system shall always zero-fill any partial page at the end of an object.
 * Further, the system shall never write out any modified portions of
 * the last page of an object which are beyond its end.

So unless they're completely misinterpreting the meaning of mmap, it
sounds like there's a bug in a number of `POSIX-compliant' operating
systems that needs to be resolved (FreeBSD and Linux included).

However, before jumping to conclusions, I think that it's prudent to
narrow down where and why this is occurring...

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

The project administrators are available, as noted, here:

https://sourceforge.net/project/memberlist.php?group_id=64592

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