[LTP] [PATCH 1/1] openposix_mmap_11_4

[LTP] [PATCH 1/1] openposix_mmap_11_4

[hefan]

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

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


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

-- 

Fan Fredrick He
R&D OPS QA Beijing PRC
Room 3603, Beijing Fortune Plaza, Office Tower A, No.7 Dongsanhuan Zhonglu, Chaoyang District, Beijing, P.R., 100020
SUSE LINUX Products
fhe@novell.com
Mainland-Mobile (86) 13661278596

[-- Attachment #2: open_posix_mmap_11-4.diff --]
[-- Type: text/x-patch, Size: 596 bytes --]

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

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

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

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

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

[Garrett Cooper]

On Thu, Jul 16, 2009 at 9:07 PM, hefan<fhe@novell.com> wrote:
> hi,

Hello!

Please read the DCO and change your reply to reflect the requirements
in the DCO: <http://ltp.sourceforge.net/DCO.txt>.

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

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

[hefan]

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

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


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

-- 

Fan Fredrick He
R&D OPS QA Beijing PRC
Room 3603, Beijing Fortune Plaza, Office Tower A, No.7 Dongsanhuan Zhonglu, Chaoyang District, Beijing, P.R., 100020
SUSE LINUX Products
fhe@novell.com
Mainland-Mobile (86) 13661278596

[-- Attachment #2: open_posix_mmap_11-4.diff --]
[-- Type: text/x-patch, Size: 596 bytes --]

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

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

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

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

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

[Garrett Cooper]

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
>
>
> 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?
4. Have you talked to the openposix test suite folks about this yet?
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 :)...

[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

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

[hefan]

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

> 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

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

[Michal Simek]

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

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

[Garrett Cooper]

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

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

[hefan]

On Mon, 2009-07-20 at 00:46 -0700, Garrett Cooper wrote:
> 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...
here in my environment the page size is 1024 got by using
sysconf(_SC_PAGE_SIZE) in this testcase
> 
> > 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.
yeah, that's the keypoint. but it doesn't terminate our userland app.

i mean that here is a mistake on the way this testcase check the result.
ideally, the mmap should only use half a page and it has no
resposibility on the rest of the page, so we shouldn't judge the mmap by
the rest of the page which is none of business with mmap.

so if we suppose that the mmap does affect the rest of the page(  is it
the purpose to design this testcase ? ), we should make sure that this
area has been clear before we mmap the file into this area. that's why i
use memset and flag MAP_FIXED.

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

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

[naresh kamboju]

Hi,

In addition to the below Link discussion

Date: 16 Jul 2009
http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg07506.html

patch is not yet committed to LTP CVs.

as per test case Description

/*****************************************************/
 * 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.
 *
 * Test step:
 * 1. Create a process, in this process:
      a. map a file  with size of 1/2 * page_size,
 *       set len = 1/2 * page_size
 *    b. Read the partial page beyond the object size.
 *       Make sure the partial page is zero-filled;
 *    c. Modify a byte in the partial page, then un-map the and close the
 *       file descriptor.
 * 2. Wait for the child proces to exit, then
 *    Map the file again,
 *    read the byte from the position modified at step 1-c and check.
 */
/****************************************************/

please note the below discussion

http://bugs.gentoo.org/197191

Ref:
http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html

fan he,

please make sure who is going to do this is it coming from kernel or glibc?

Best regards
Naresh Kamboju


>On Mon, 2009-07-20 at 00:46 -0700, Garrett Cooper wrote:
> On Sun, Jul 19, 2009 at 10:54 PM, Michal
> Simek<michal.si...@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<f...@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 <f...@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...
here in my environment the page size is 1024 got by using
sysconf(_SC_PAGE_SIZE) in this testcase
>
> > 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.
>yeah, that's the keypoint. but it doesn't terminate our userland app.

>i mean that here is a mistake on the way this testcase check the result.
>ideally, the mmap should only use half a page and it has no
>resposibility on the rest of the page, so we shouldn't judge the mmap by
>the rest of the page which is none of business with mmap.

>so if we suppose that the mmap does affect the rest of the page(  is it
>the purpose to design this testcase ? ), we should make sure that this
>area has been clear before we mmap the file into this area. that's why i
>use memset and flag MAP_FIXED.

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

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

[Subrata Modak]

On Thu, 2009-08-06 at 21:39 +0530, naresh kamboju wrote: 
> Hi,
> 
> In addition to the below Link discussion
> 
> Date: 16 Jul 2009
> http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg07506.html
> 
> patch is not yet committed to LTP CVs.

I am a bit perplexed by all these links. Can you please RESEND the
concerned patch with the required description. I would then check that
in.

Regards--
Subrata

> 
> as per test case Description
> 
> /*****************************************************/
>  * 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.
>  *
>  * Test step:
>  * 1. Create a process, in this process:
>       a. map a file  with size of 1/2 * page_size,
>  *       set len = 1/2 * page_size
>  *    b. Read the partial page beyond the object size.
>  *       Make sure the partial page is zero-filled;
>  *    c. Modify a byte in the partial page, then un-map the and close the
>  *       file descriptor.
>  * 2. Wait for the child proces to exit, then
>  *    Map the file again,
>  *    read the byte from the position modified at step 1-c and check.
>  */
> /****************************************************/
> 
> please note the below discussion
> 
> http://bugs.gentoo.org/197191
> 
> Ref:
> http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html
> 
> fan he,
> 
> please make sure who is going to do this is it coming from kernel or glibc?
> 
> Best regards
> Naresh Kamboju
> 
> 
> >On Mon, 2009-07-20 at 00:46 -0700, Garrett Cooper wrote:
> > On Sun, Jul 19, 2009 at 10:54 PM, Michal
> > Simek<michal.si...@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<f...@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 <f...@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...
> here in my environment the page size is 1024 got by using
> sysconf(_SC_PAGE_SIZE) in this testcase
> >
> > > 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.
> >yeah, that's the keypoint. but it doesn't terminate our userland app.
> 
> >i mean that here is a mistake on the way this testcase check the result.
> >ideally, the mmap should only use half a page and it has no
> >resposibility on the rest of the page, so we shouldn't judge the mmap by
> >the rest of the page which is none of business with mmap.
> 
> >so if we suppose that the mmap does affect the rest of the page(  is it
> >the purpose to design this testcase ? ), we should make sure that this
> >area has been clear before we mmap the file into this area. that's why i
> >use memset and flag MAP_FIXED.
> 
> >
> > 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


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

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

[naresh kamboju]

Hi Fan,

please give your comments on this issue.

It is glibc and kernel issue discussions.

http://bugs.gentoo.org/197191

Is this info is up to the date?

 http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html

I did not find mmap (3) in kernel man pages.

http://www.kernel.org/doc/man-pages/online/dir_section_3.html

I am not sure about glibc mmap implementation.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=glibc

if you find any info.
please share.

Best regards,
Naresh Kamboju

On Fri, Aug 7, 2009 at 6:11 PM, Subrata Modak<subrata@linux.vnet.ibm.com> wrote:
> On Thu, 2009-08-06 at 21:39 +0530, naresh kamboju wrote:
>> Hi,
>>
>> In addition to the below Link discussion
>>
>> Date: 16 Jul 2009
>> http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg07506.html
>>
>> patch is not yet committed to LTP CVs.
>
> I am a bit perplexed by all these links. Can you please RESEND the
> concerned patch with the required description. I would then check that
> in.
>
> Regards--
> Subrata
>
>>
>> as per test case Description
>>
>> /*****************************************************/
>>  * 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.
>>  *
>>  * Test step:
>>  * 1. Create a process, in this process:
>>       a. map a file  with size of 1/2 * page_size,
>>  *       set len = 1/2 * page_size
>>  *    b. Read the partial page beyond the object size.
>>  *       Make sure the partial page is zero-filled;
>>  *    c. Modify a byte in the partial page, then un-map the and close the
>>  *       file descriptor.
>>  * 2. Wait for the child proces to exit, then
>>  *    Map the file again,
>>  *    read the byte from the position modified at step 1-c and check.
>>  */
>> /****************************************************/
>>
>> please note the below discussion
>>
>> http://bugs.gentoo.org/197191
>>
>> Ref:
>> http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html
>>
>> fan he,
>>
>> please make sure who is going to do this is it coming from kernel or glibc?
>>
>> Best regards
>> Naresh Kamboju
>>
>>
>> >On Mon, 2009-07-20 at 00:46 -0700, Garrett Cooper wrote:
>> > On Sun, Jul 19, 2009 at 10:54 PM, Michal
>> > Simek<michal.si...@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<f...@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 <f...@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...
>> here in my environment the page size is 1024 got by using
>> sysconf(_SC_PAGE_SIZE) in this testcase
>> >
>> > > 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.
>> >yeah, that's the keypoint. but it doesn't terminate our userland app.
>>
>> >i mean that here is a mistake on the way this testcase check the result.
>> >ideally, the mmap should only use half a page and it has no
>> >resposibility on the rest of the page, so we shouldn't judge the mmap by
>> >the rest of the page which is none of business with mmap.
>>
>> >so if we suppose that the mmap does affect the rest of the page(  is it
>> >the purpose to design this testcase ? ), we should make sure that this
>> >area has been clear before we mmap the file into this area. that's why i
>> >use memset and flag MAP_FIXED.
>>
>> >
>> > 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
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

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

[Subrata Modak]

Any updates on this ?

Regards--
Subrata

On Fri, 2009-08-07 at 21:29 +0530, naresh kamboju wrote: 
> Hi Fan,
> 
> please give your comments on this issue.
> 
> It is glibc and kernel issue discussions.
> 
> http://bugs.gentoo.org/197191
> 
> Is this info is up to the date?
> 
>  http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html
> 
> I did not find mmap (3) in kernel man pages.
> 
> http://www.kernel.org/doc/man-pages/online/dir_section_3.html
> 
> I am not sure about glibc mmap implementation.
> 
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=glibc
> 
> if you find any info.
> please share.
> 
> Best regards,
> Naresh Kamboju
> 
> On Fri, Aug 7, 2009 at 6:11 PM, Subrata Modak<subrata@linux.vnet.ibm.com> wrote:
> > On Thu, 2009-08-06 at 21:39 +0530, naresh kamboju wrote:
> >> Hi,
> >>
> >> In addition to the below Link discussion
> >>
> >> Date: 16 Jul 2009
> >> http://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg07506.html
> >>
> >> patch is not yet committed to LTP CVs.
> >
> > I am a bit perplexed by all these links. Can you please RESEND the
> > concerned patch with the required description. I would then check that
> > in.
> >
> > Regards--
> > Subrata
> >
> >>
> >> as per test case Description
> >>
> >> /*****************************************************/
> >>  * 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.
> >>  *
> >>  * Test step:
> >>  * 1. Create a process, in this process:
> >>       a. map a file  with size of 1/2 * page_size,
> >>  *       set len = 1/2 * page_size
> >>  *    b. Read the partial page beyond the object size.
> >>  *       Make sure the partial page is zero-filled;
> >>  *    c. Modify a byte in the partial page, then un-map the and close the
> >>  *       file descriptor.
> >>  * 2. Wait for the child proces to exit, then
> >>  *    Map the file again,
> >>  *    read the byte from the position modified at step 1-c and check.
> >>  */
> >> /****************************************************/
> >>
> >> please note the below discussion
> >>
> >> http://bugs.gentoo.org/197191
> >>
> >> Ref:
> >> http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html
> >>
> >> fan he,
> >>
> >> please make sure who is going to do this is it coming from kernel or glibc?
> >>
> >> Best regards
> >> Naresh Kamboju
> >>
> >>
> >> >On Mon, 2009-07-20 at 00:46 -0700, Garrett Cooper wrote:
> >> > On Sun, Jul 19, 2009 at 10:54 PM, Michal
> >> > Simek<michal.si...@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<f...@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 <f...@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...
> >> here in my environment the page size is 1024 got by using
> >> sysconf(_SC_PAGE_SIZE) in this testcase
> >> >
> >> > > 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.
> >> >yeah, that's the keypoint. but it doesn't terminate our userland app.
> >>
> >> >i mean that here is a mistake on the way this testcase check the result.
> >> >ideally, the mmap should only use half a page and it has no
> >> >resposibility on the rest of the page, so we shouldn't judge the mmap by
> >> >the rest of the page which is none of business with mmap.
> >>
> >> >so if we suppose that the mmap does affect the rest of the page(  is it
> >> >the purpose to design this testcase ? ), we should make sure that this
> >> >area has been clear before we mmap the file into this area. that's why i
> >> >use memset and flag MAP_FIXED.
> >>
> >> >
> >> > 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
> >
> >


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list