VDSO for arm 32bit

[Dave Martin]

On Wed, May 29, 2013 at 10:01:40AM -0400, Nicolas Pitre wrote:
> On Wed, 29 May 2013, Will Deacon wrote:
> 
> > On Tue, May 28, 2013 at 07:19:00PM +0100, Nicolas Pitre wrote:
> > > On Tue, 28 May 2013, Will Deacon wrote:
> > > > Be careful here. I had a crack at a gtod implementation for the vectors page
> > > > in the past, but decided to drop it because it quickly became a maintenance
> > > > nightmare. Since the layout of the vectors page must be fixed (as userspace
> > > > jumps to the absolute addresses for the helpers), having large, complicated
> > > > functions (which gtod does become as you quickly start using the stack to
> > > > store all of the shared state with the kernel) means that you can quickly
> > > > back yourself into a corner where the layout of the code cannot change
> > > > without breaking the ABI.
> > > 
> > > Note that only the entry point is fixed.  The layout of the code is not.  
> > > So you may well branch anywhere else within the vector page if the code 
> > > is more complex than a few instructions.
> > 
> > Sure, it may be possible simply to have branches in the kuser slots and then
> > reserve a chunk at the other end of the vectors page where the actual
> > implementation can go.
> > 
> > > > On top of that, new clock types are added more often than you might think
> > > > (not to mention bug fixes in the implementation itself), and you end up in
> > > > a horrible situation where you'd end up deprecating one implementation and
> > > > adding gettimeofday2 or something equally nasty at a different offset.
> > > 
> > > That is equally valid for a vdso.
> > 
> > Sorry, I wasn't clear. My point was that you can change the layout of a vdso
> > without breaking anything, since the dynamic loader resolves the entry
> > points. It relates back to what I said above -- you need to be careful about
> > how you lay the stuff out in memory.
> > 
> > Perhaps the gtod code won't end up being that big. It's around ~500 bytes on
> > arm64, but that's without any stack usage.
> 
> That's still fairly large.
> 
> > Come to think of it, is there any
> > reason why we can't just map an additional vectors page after the one we
> > currently have?
> 
> That certainly can be done if necessary.  Some copy_page implementations 
> do use some of the address space above the vector page for temporary 
> page mapping so some care not to create conflicts would be required.

In theory, we could have a VDSO wrapping the vectors page.  This could allow
the existing kuser helpers to be looked up by ELF symbol as well as the well-
known address.  New functions don't necessarily need to have a well-known
address at all -- they might only be visible as ELF symbols, since there is
no need to offer a backwards-compatible ABI for new functions.

Alternatively, we could have a VDSO which is separate from the vectors
page, exporting only the new functionality, with the vectors page remaining
as before.

Whether or not adding a VDSO brings enough benefit to make it worthwhile
is a separate discussion, though.

Cheers
---Dave