The vDSO page is getting in the way of applications on i686 (i386).
There is a performance problem, a problem with a dangling pointer
in the kernel, and a loss of control in the kernel<->user interface.
A possible solution might be a new system call to move the vDSO page.
Performance: the kernel chooses the vDSO page after mapping the main
program and the PT_INTERP [see fs/binfmt_elf.c]. If pre-linking chose
that same page for some subsequent shared library, then the pre-linking
is discarded, which costs time. In Fedora Core 4 i686 with random vDSO
placement, the probability is about 7% that a main program with just one
shared library must relocate libc.so.6. Cascading conflicts and costs
are likely; a program with dozens of shared libs is almost certain
to require expensive runtime relocation processing of shared libraries.
Dangling pointer: setup_frame() in arch/i386/kernel/signal.c uses
restorer = current->mm->context.vdso + (long)&__kernel_sigreturn;
whenever !(.sa_flags & SA_RESTORER). Unfortunately, context.vdso is
never changed, so if the user re-maps the vDSO page then the kernel
has a dangling pointer which makes user return from signal unreliable.
Loss of control: in a 32-bit address there are at most one million
4KB pages. Maintaining contiguous ranges for large arrarys is a problem.
Having no control over placement of the vDSO page makes things worse.
Programs that audit or measure the running of other programs in the
same address space, desire to place the vDSO page after mapping
the programs that are being examined.
Possible solution: a new system call move_vdso(old_addr, new_addr, flags).
Check that current vDSO was at old_addr, else error. Change vDSO page
under control of flags like in mmap(): new_addr is hint (place to start
search) or required address if MAP_FIXED. Return value is new vDSO address.
For some history and examples see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162797
Comments?
--
John Reiser, [email protected]
On Monday 12 December 2005 16:29, John Reiser wrote:
> Possible solution: a new system call move_vdso(old_addr, new_addr, flags).
> Check that current vDSO was at old_addr, else error. Change vDSO page
> under control of flags like in mmap(): new_addr is hint (place to start
> search) or required address if MAP_FIXED. Return value is new vDSO address.
>
What about special casing the vDSO page in mremap() ?
Regards
Ingo Oeser
Ingo Oeser wrote:
> On Monday 12 December 2005 16:29, John Reiser wrote:
>
>>Possible solution: a new system call move_vdso(old_addr, new_addr, flags).
>>Check that current vDSO was at old_addr, else error. Change vDSO page
>>under control of flags like in mmap(): new_addr is hint (place to start
>>search) or required address if MAP_FIXED. Return value is new vDSO address.
>>
>
>
> What about special casing the vDSO page in mremap() ?
Hmmm... Where can the new address [hint] be given in the call to
mremap(old_address, old_size, new_size, flags) ?
Also: probably the size is constant, perhaps even unknown to the user.
It would be nice if the old page need not exist (could have been
mmap()ed over) at the time of the move, although the proposed
move_vdso() does ask for what the old_addr used to be, as a check
on validity.
--
John Reiser, [email protected]