[CRIU] [PATCH 1/4] vdso: Introduce vdso engine

[Cyrill Gorcunov]

In this patch we prepare vdso engine to be used in future patches
for vdso proxification.

This patch implements the structures/helpers needed: allows us
to parse vdso structure and patch the calls converting it
to vdso proxy, where all calls to the dumpee vdso will be redirected
to run time vdso obtained from the running kernel.

Here a few words over the vDSO proxification in general.

There might be two situation when we're restoring vdso area of a dumpee

1)  The checkpoint done on the same kernel or on the kernel
    where vdso has not been changed.

2)  The checkpoint done on the different kernel where vdso
    is different from one current kernel provides.

For case (1) what we can do is to remap runtime vdso to a new place
where dumpee expects it to be found. Thus we don't generate any proxy.
Because rt-vdso need to be saved somewhere before we can remap it
in new place, we reserve memory area in restorer blob, and remap
it there in pie restorer code (we can't do that earlier because
our criu code uses it in log engine). Then at moment of mapping
new memory map obtained from image we find vdso zone bounds and
substitute it with rt-vdso from restorer blob. Finally the dumpee
will have new vdso obtained from the kernel and placed at old
vdso site.

For case (2) we need a more complex logic -- we need to proxify calls.
This is done in a few steps. At first, when we create big slab for
premapped private vmas, we detect dumpee vdso area and remember its
parameters (because we don't know yet where restorer blob will be
placed and thus where rt-vdso can be kept). Then once restorer blob
is allocated and rt-vdso address is known we patch dumpee vdso to
redirect calls, and dumpee vdso become a proxy. Again, we patch
dumpee early, but real remap of rt-vdso to a known place happens
later in restorer code for exactly same reason as in (1) -- our
log engine uses rt-vdso.

Another problem in scenario (2) -- when program is restored we
will have two vdso areas in memory: proxy and rt, and there is
no easy way to detect who is who (in further dump actions). So
to resolve this situation we poke rt-vdso elf header and put
that named vdso-mark there.

Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
---
 Makefile.crtools            |   1 +
 arch/arm/include/asm/vdso.h |  25 ++++
 arch/x86/Makefile           |   1 +
 arch/x86/include/asm/vdso.h |  25 ++++
 arch/x86/vdso.c             | 301 ++++++++++++++++++++++++++++++++++++++++++++
 include/vdso.h              | 180 ++++++++++++++++++++++++++
 vdso.c                      | 132 +++++++++++++++++++
 7 files changed, 665 insertions(+)
 create mode 100644 arch/arm/include/asm/vdso.h
 create mode 100644 arch/x86/include/asm/vdso.h
 create mode 100644 arch/x86/vdso.c
 create mode 100644 include/vdso.h
 create mode 100644 vdso.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-vdso-Introduce-vdso-engine.patch
Type: text/x-patch
Size: 17229 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130522/f3565f70/attachment-0001.bin>