[CRIU] [PATCH 5/5] vdso: x86 -- Add handling of vvar zones

[Pavel Emelyanov]

On 06/10/2014 10:16 PM, Cyrill Gorcunov wrote:
> 
> New kernel 3.16 will have old vDSO zone splitted into the two vmas:
> one for vdso code itself and second that named vvar for data been
> referenced from vdso code.
> 
> Because I can't do 'dump' and 'restore' parts of the code separately
> (otherwise test would fail) the commit is pretty big one and hard to
> read so here is detailed explanation what's going on.
> 
>  1) When start dumping we detect vvar zone by reading /proc/pid/smap
>     and looking up for "[vvar]" token. Note the vvar zone is mapped
>     by a kernel with PF/IO flags so we should not fail here.
> 
>     Also it's assumed that at least for now kernel won't be changed
>     much and [vvar] zone always follows the [vdso] zone, otherwise
>     criu will print error.
> 
>  2) In previous commits we disabled dumping vvar area contents so
>     the restorer code never try to read vvar data but still we need
>     to map vvar zone thus vma entry remains in image.
> 
>  3) As with previous vdso format we might have 2 cases
> 
>     a) Dump and restore is happening on same kernel
>     b) Dump and restore are done on different kernels
> 
>     To detect which case we have we parse vdso data from image
>     and find symbols offsets then compare their values with runtime
>     symbols provided us by a kernel. If they match and (!!!) the
>     size of vvar zone is the same -- we simply remap both zones
>     from runtime kernel into the positions dumpee had at checkpoint
>     time. This is that named "inplace" remap (a).
> 
>     If this happens the vdso_proxify() routine drops VMA_AREA_REGULAR
>     from vvar area provided by a caller code and restorer won't try
>     to handle this vma. It looks somehow strange and probably should
>     be reworked but for now I left it as is to minimize the patch.
> 
>     In case of (b) we need to generate a proxy. We do that in same
>     way as we were before just include vvar zone into proxy and save
>     vvar proxy address inside vdso mark injected into vdso area. Thus
>     on subsequent checkpoint we can detect proxy vvar zone and rip
>     it off the list of vmas to handle.
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
>  arch/x86/include/asm/vdso.h |   9 ++-
>  arch/x86/vdso-pie.c         |  71 +++++++++++++++++-----
>  arch/x86/vdso.c             | 141 ++++++++++++++++++++++++++++++++++++--------
>  cr-restore.c                |   4 +-
>  include/vdso.h              |   3 +-
>  pie/restorer.c              |  28 ++++++++-
>  proc_parse.c                |  21 ++++++-
>  7 files changed, 229 insertions(+), 48 deletions(-)
> 


> #ifdef CONFIG_VDSO
>  		if (vma_entry_is(vma_entry, VMA_AREA_VDSO)) {
> +			VmaEntry *vma_vvar;
> +
> +			if (i + 1 < args->nr_vmas) {
> +				vma_vvar = args->tgt_vmas + i + 1;
> +				if (!vma_entry_is(vma_entry, VMA_AREA_VVAR))
> +					vma_vvar = NULL;
> +			} else
> +				vma_vvar = NULL;

So why do you consider vvar vma _in_ _images_ to strictly follow the vdso one?