Grr.. for some reason this didn't seem to get through the first time.
On Tue, Jan 02, 2007 at 09:04:17AM -0600, Adam Litke wrote:
> On Wed, 2006-12-20 at 20:08 -0800, Nishanth Aravamudan wrote:
> > Well, I'm looking at the numbering more from an ABI/feature perspective.
> > Technically, our ABI was unchanged by the daemon removal (see
> > version.lds), as the few functions we export are unchanged. The feature
> > set is being reduced by (the following) patch, though, which may
> > necessitate a minor revision bump. Technically, we've not added any
> > features, though, which (to me) would be more what 1.1 represents... Oh
> > well, I'll see if I can't find any documentation somehwere on GNU
> > versioning semantics.
> >
> > Remove the ability to share writable segments from the library, by
> > ignoring any value of HUGETLB_SHARE other than 1. This is necessary due
> > to difficulties sharing writable segments on x86_64.
> >
> > Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
>
> Hmm... At the very least, I think we need to update this patch comment
> (for the commit log) to say the difficulties are caused by address space
> randomization. But that said, would it make sense when HUGETLB_SHARE ==
> 2, to check the randomize_va_space sysctl and refuse to share only if it
> is enabled? If we discover further problems later we could take this
> more drastic approach. Thoughts?
I don't think this is a good idea. The fact is, given that we're not
starting until some variables in the program's BSS and/or data
segments are initialized, there's absolutely no guarantee what they'll
be initialized to - or that it will be the same value on each run. It
happens to be the case that without address space randomization, they
seem to end up with the same values - for any variables we've hit so
far, and for the current version of libc. I think relying on this is
likely to be fragile. If nothing else, we know that changing the map
address of libc breaks this, and i's entirely possible there could be
reasons other than randomize_va_space for libc not to be mapped at a
consistent address.
--
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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
