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

[Oren Laadan]

Serge E. Hallyn wrote:
> 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.

Actually, I think that the get_gate_vma() is broken with randomized vdso
in the main kernel - it simply won't work just like remapping won't work :)
It simply didn't show up so far either because no-one is using it, or the
function is not really important ?

Who would be the right person to report this issue ?

> 
> 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?

I fear that if we require that, then we forget to un-require it later ...

Another thing that we should do it transder the vdso page (one copy of
each page) from the checkpoint and compare to the version available at
the restart. Yell if differs.

(vdso page pointer will be treated as a shared resource - so only copied
once).

Oren.

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