> Here is a successful fault for the address of interest -- a different > thread in the same run on the app: > > 0 clomp5_wopr7(6975):->aufs_nopage (vma=0xffff8101ffcd28c8 file=0xffff81 > 01feb04dc0(aufs)/:lib64/libm-2.5.so addr=0x00002aaaaaeef000) > 24 clomp5_wopr7(6975): ->au_fi (file=0xffff8101feb04dc0[(aufs)/:lib64/lib > m-2.5.so], h_file=0xffff8101feb04dc0[(aufs)/:lib64/libm-2.5.so] > 68 clomp5_wopr7(6975): ->filemap_nopage (file=0xffff8101feb044c0[(nfs)/ > :lib64/libm-2.5.so] addr=0x00002aaaaaeef000) > 86 clomp5_wopr7(6975): ->find_get_page (offset=36 owner=nfs) > 117 clomp5_wopr7(6975): <-find_get_page (0xffff81000b44d3d8 (flags=0x00 > c808000000006c)) > 131 clomp5_wopr7(6975): <-filemap_nopage (rc=0xffff81000b44d3d8) > 143 clomp5_wopr7(6975): <-aufs_nopage (rc=0xffff81000b44d3d8)
Well, now I just noticed that the hidden file in this successful run does *not* point to the NFS file, but is instead the aufs file. However, notice that by the time we enter filemap_nopage() area->vm_file is back to the nfs file. I think this still seems to point to a race in aufs_nopage(). Sorry if this tracing is just causing confusion. mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
