ppc64 vDSO in mainline

[Benjamin Herrenschmidt]

On Mon, 2005-03-28 at 12:51 -0800, Roland McGrath wrote:
> > Ok, but there was another reason in the back of my mind for wanting to
> > keep the vDSO virtual address flexible: The current choice of the map
> > address for it was done rather arbitrarily (+1Mb). It appears that
> > pretty much nobody uses that space currently. However, it removes some
> > flexibility from userland programs over the layout of their address
> > space (things like emulators etc... may want greater control). So I had
> > in mind the possibility in the future of defining some sort of ELF
> > program header enter that would force the kernel to map the vDSO at a
> > different address for a given binary.
> 
> This is already covered adequately by the spec.  A program has to give
> phdrs covering any space it wants reserved for its own use, and anything
> else is up for grabs by the OS.  If the vdso mapping just does the normal
> thing (get_unmapped_area with or without a hint address, but no MAP_FIXED),
> it will do all the right things. 

It's currently not using get_unmapped_area() but that could/should be
fixed. The problem is that a the current implementation maps the vDSO in
before the program. This is due to an historical fact with the initial
implementation which I did make sit above the stack, and thus required
to be setup before the stack. This is no longer the case though, so I
suppose I should move that bit and fix things up.

> If you give a hint, that will usually be the address, but not if there is a
> conflict with the executable's segments.
> If you don't give a hint, the address assigned will be predictable
> (i.e. repeat the same on a given installation), or else be randomized when
> that is done for other mappings, just like normal DSO mappings are.

Yup. I definitely need to revisit that part of the implementation.

Ben.