On Mon, Jan 05, 2009 at 11:08:53AM -0800, mehul vora wrote: > Adam, > > I tried that, but gdb receives SIGSEGV immediately after calling > "munmap"... GDB shows the fault address as a "next to `munmap` jump > instruction". I took objdump of the image to confirm this. > > But i believe, program is getting an exception while returning from > munmap syscall. As it tries to jump back to the user space > address, but doesn't find any valid tlb / page table entry and it > takes a invalid fault.. > > I am still not able to understand that how any architecture would > allow access to any "unmapped" segment without any page table / tlbs > info ? Is the "constructor" code in libhugetlbfs sits under any > specific segment other than ".text" which is never unmapped ??
They don't. You can't access unmapped memory. What has to happen in this piece of code is that we don't touch any of the unmapped segments between the unmap() and the re-map. The remapping code itself is in the libhugetlbfs segment, not the main program which means its available, and we avoid calling any libc functions which would require accessing the PLT. This is sufficient on x86 and powerpc. Apparently there's something different on the MIPS ABI which means that one of the unmapped addresses is being touched in the black-hole zone. We'll have to work out exactly what, and why, and see if we can figure out a way to avoid it. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ------------------------------------------------------------------------------ _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel