Menu
▾
▴
Re: [LTP] [PATCH 1/1] openposix_mmap_11_4
|
From: Subrata M. <su...@li...> - 2009-08-10 08:21:37
|
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<su...@li...> 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...@li.../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 > > > > |