On Sun, Jul 19, 2009 at 10:54 PM, Michal Simek<[email protected]> wrote: > Hi, >> On Sat, 2009-07-18 at 12:28 -0700, Garrett Cooper wrote: >> >>> On Thu, Jul 16, 2009 at 11:37 PM, hefan<[email protected]> 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 <[email protected]> >>>> >>>> --- >>>> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
