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

Reply via email to