From: hefan <fh...@no...> - 2009-07-20 05:15:10
|
On Sat, 2009-07-18 at 12:28 -0700, Garrett Cooper wrote: > On Thu, Jul 16, 2009 at 11:37 PM, hefan<fh...@no...> 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 <fh...@no...> > > > > --- > > 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 > ro...@op...:/usr/obj/usr/src/sys/OPTIMUS > amd64 > > Thanks, > -Garrett |