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

[Subrata Modak <subrata@linux.vnet.ibm.com>]

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