Re: + fully-honor-vdso_enabled.patch added to -mm tree

[Oleg Nesterov <oleg@tv-sign.ru>]

On 03/02, Paul Mundt wrote:
>
> On Thu, Mar 01, 2007 at 08:52:07PM +0300, Oleg Nesterov wrote:
> > >
> > > @@ -105,10 +107,25 @@ int arch_setup_additional_pages(struct l
> > >  {
> > >  	struct mm_struct *mm = current->mm;
> > >  	unsigned long addr;
> > > +	unsigned long flags;
> > >  	int ret;
> > >
> > > +	switch (vdso_enabled) {
> > > +	case 0:  /* none */
> > > +		return 0;
> > 
> > This means we don't initialize mm->context.vdso and ->sysenter_return.
> > 
> > Is it ok? For example, setup_rt_frame() uses VDSO_SYM(&__kernel_rt_sigreturn),
> > sysenter_past_esp pushes ->sysenter_return on stack.
>
> The setup_rt_frame() case is fairly straightforward, both PPC and SH
> already check to make sure there's a valid context before trying to use
> VDSO_SYM(), I'm not sure why x86 doesn't.
>
> Though I wonder if there's any point in checking binfmt->hasvdso here?
> There shouldn't be a valid mm->context.vdso in the !hasvdso case..

setup_rt_frame() is obviously wrong? Surely it must check ->hasvdso like
setup_frame() does! Otherwise, we will have SIGSEGV on SA_SIGINFO if
->load_binary() does not call arch_setup_additional_pages(), no?

If no, what ->hasvdso is?

> Someone else will have to comment on ->sysenter_return.

It is needed for sysexit. If we don't use sysenter (and we shouldn't, because
syscall_page is not mapped), we don't need to initialize it. Note also that
sys_execve() sets TIF_IRET, so we are safe even if sys_execve() was called
using __kernel_vsyscall.

Still, I don't understand why we don't pass NEW_AUX_ENT(AT_SYSINFO) when
vdso_enabled == 0. We don't need linux-gate.so to use __kernel_vsyscall,
we have FIX_VDSO. In that case we should s/PAGE_KERNEL_RO/PAGE_READONLY/
of course. I guess the reason is some magic in glibc.

Oleg.