[Devel] Re: [PATCH 1/1] cr: remap vdso at original address

[Serge E. Hallyn]

Quoting Oren Laadan (orenl at cs.columbia.edu):
> 
> 
> Serge E. Hallyn wrote:
> > Well, here is my current attempt at properly handling vdso for
> > the x86 and s390 c/r code.  I was going to test with gettimeofday,
> > but x86 doesn't use vdso for that, and I'm still recompiling glibc
> > on s390 to exploit vdso for it.  So what I can tell so far is that
> > CONFIG_COMPAT_VDSO=n is now save on x86 - the kernel vdso segment
> > is re-mapped from the kernel into the checkpointed location, so
> > the fact that the task was started with a random vdso base doesn't
> > matter.
> > 
> > Once I get a proper testcase, I intend to show that checkpointing
> > a testcase which does gettimeofday(), waiting 10 seconds, and
> > then restarting it, will end up with bad __vdso_gettimeofday()
> > results without this patch, and good ones with it.
> 
> It will be helpful if you split the patch into non-c/r changes (i.e.
> add a parameter to request mapping for vdso), following by c/r changes
> per architecture.

Actually, since sending this patch I've been trying to exercise the
vdso on 4 different systems (s390, x86, powerpc).  Only on powerpc
was i able to confirm vdso was being used, and there not having this
patch made zero difference.

So right now I'm thinking the only thing that is needed is to either
demand COMPAT_VDSO=y on x86, or to take the part of this patch where
we reset context.vdso.

> Also, I noticed that it may be more complicated. For example, the
> function get_gate_vma() (at least on x86) test the value of context.vdso
> against some constant to decide on the return value. I don't know if
> this will break if the vdso of a task ends up being something that the
> system didn't expect it to be ?

Yeah that logic will need a tweak, thanks.

But so for now I'm definately withdrawing this patch.  In the meantime,
do we prefer requiring COMPAT_VDSO (using config logic?), or do we
prefer resetting the context.vdso on x86 at restart?

thanks,
-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers