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

[Paul Mundt]

On Thu, Mar 01, 2007 at 08:52:07PM +0300, Oleg Nesterov wrote:
> > --- a/arch/i386/kernel/sysenter.c~fully-honor-vdso_enabled
> > +++ a/arch/i386/kernel/sysenter.c
> > @@ -22,6 +22,8 @@
> >  #include <asm/msr.h>
> >  #include <asm/pgtable.h>
> >  #include <asm/unistd.h>
> > +#include <asm/a.out.h>
> > +#include <asm/mman.h>
> >
> >  /*
> >   * Should the kernel map a VDSO page into processes and pass its
> > @@ -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..

Someone else will have to comment on ->sysenter_return.

Signed-off-by: Paul Mundt <lethal@xxxxxxxxxxxx>

--

 arch/i386/kernel/signal.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/i386/kernel/signal.c b/arch/i386/kernel/signal.c
index 4f99e87..f778d34 100644
--- a/arch/i386/kernel/signal.c
+++ b/arch/i386/kernel/signal.c
@@ -350,7 +350,7 @@ static int setup_frame(int sig, struct k_sigaction *ka,
 			goto give_sigsegv;
 	}
 
-	if (current->binfmt->hasvdso)
+	if (current->binfmt->hasvdso && current->mm->context.vdso)
 		restorer = (void *)VDSO_SYM(&__kernel_sigreturn);
 	else
 		restorer = (void *)&frame->retcode;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/