On 05.01.2009 [06:26:55 -0800], mehul vora wrote: > Nishanth, > > I went through "munmap" code and found that core kernel (arch > independent) code removes all "vma" references of the passed vaddr and > then it calls arch dependent hooks. MIPS code removes all pagetable > reference of the passed vaddr and flushes tlbs on all cpus. So after > munmap returns, if process will try to access the same address again > then it will receive a SIGSEGV signal.
We do call it a black hole, as I've said :) It's hairy code. > I wrote a simple program (not linked with libhugetlbfs - see > attachment) to cross check this on MIPS. The moment program does the > "munmap" of the code segment it immediately receives a SIGSEGV. Same > program also crashes on x86 with SIGSEGV. Right, I see that. > Is this program, at a high level, very similar to libhugetlb init > (constructor - munmap/mmap sequence) code ? If yes, then, Is there > anything specific libhugetlbfs does before unmapping the code segment > apart from copying all segments in to hugepages to make this work ? A few thoughts: we don't unmap all segments, only those that need to be remapped. Not sure if that matters. The only external reference we resolve between unmapping and mapping is mmap(), which is why we have that false mmap() call. So, nothing else should access the text segment between unmap and map in libhugetlbfs. I know libhugetlbfs works on x86 :) I'll think about it further. Maybe someone else will have some ideas. -Nish -- Nishanth Aravamudan <n...@us.ibm.com> IBM Linux Technology Center ------------------------------------------------------------------------------ _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
