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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
