int32 with boolean value in protobuf has the same size with bool,
many sysctls are boolean but we don't lose anything by storing them
in int32, so add only int32 and string fields
will need string field for stable_secret ipv6 sysctl
also such fromat allows us to easily handle non-present int sysctls
we can check if we have it using has_*arg
v3: rebase images/Makefile to criu-dev branch
v4: use enum for type
Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Reviewed-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Fixes restoring on AMBA serial line. That is /dev/ttyAMA0,
which is the default serial port to use on qemu-system-aarch64.
(at least in those articles, which I meet it's in boot cmdline)
Also should add support for C/R /dev/ttyUSB*
One may check major numbers on
https://www.kernel.org/doc/Documentation/devices.txt
Also by grepping on kernel repository.
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
In commit 9469dae61c we've dropped implicit cleanups as
a pattern but in images dir we use additional custom
rules so simply drop files built.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Each time I type `make clean` and find that my tags are cleaned
and generated headers/c-files are deleted, I'm getting annoyed.
Mostly it's about protobuf images definitions.
(And then I need to run `make` and `make tags` again which
is painful).
I think, we may separate clean process on two parts, just
like it's done in the kernel (omitting distclean):
o Cleaning all binaries/objects, but leave enough to navigate
o Clean everything compiled/generated/etc.
In this patch pie blobs are still deleted on clean stage - I may
fix it in the later patches.
(they _should_ be regenerated on `make clean && make`)
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
cgroup namespaces are imminent to be merged into the kernel (indeed, they
went into and out of 4.5 for minor issues), and will be carried as a
patchset in the ubuntu 16.04 kernel. Here's an attempt at c/r.
There are essentially three key steps:
* on dump, in parse_task_cgroup, we should ask the task what cgroups it
thinks it is in (unless it has the same cgroup ns id as its parent, then we
should just take the prefixes from the parent's set), and set the prefix on
the cg set
* add a new restore step, prepare_cgroup_namespace(), which happens in
prepare_task_cgroup() that does an unshare() if necessary
* when restoring, in move_in_cgroup, if we're going to restore via usernsd,
leave the full path. if not, use (cgset->path + len(cgset->cgns_prefix) as
the path, since we will have already moved into the cgns_prefix and unshared.
Another observation here is that we can support nesting, since these are
restored heirarchically by nature.
v2: * store cgns prefix length instead of full prefix in images
* set has_cgroup_ns_id conditionally
* drop unused argument to move_in_cgroup
* add extra comments about what is happening when unsharing() on
restore
* add extra comments about what is happening when computing the actual
cgns prefix
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
This reverts commit a98014f306be4b4fefdf01af31e1efa5d83e5e4f.
As per Saied Kazemi, actually dump works without seccomp support
from the kernel on non-seccomped tasks. The only problem was with
criu check, but this would be addressed separately.
Reverting the commit not to burden the API with (yet) unneeded stuff.
Conflicts:
lib/c/criu.h
How to restore an external file? The problem is that a file
can be opened with different flags (O_APPNED, O_RDWR, O_RONLY,
etc). These flags can't be changed for a file descriptor, so
we can't just duplicate an inherit fd, when we meet an external
file.
A file is external, when we can't access them directly.
CRIU is able to restore a file descriptor, if it knows
how to open it, so we need to provide a way to open
an external file.
The idea of this patch is that we can open an external file
via /proc/self/fd/X where X is an inherit fd.
This approach works for files and fifo.
An example how it can be used:
criu -o dump.log -D dump/fifo.py/6/1 -v4 -t 6 --external file[72:a3e7]
criu -o restore.log -D dump/fifo.py/6/1 -v4 --restore-sibling --inherit-fd fd[4]:file[72:a3e7] --restore-detached
https://github.com/xemul/criu/issues/104
Cc: Saied Kazemi <saied@google.com>
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Sometimes we may want to use CRIU on older kernels which don't support
dumping seccomp state where we don't actually care about the seccomp state.
Of course this is unsafe, but it does allow for c/r of things using
seccomp on these older kernels in some cases. When the task is in
SECCOMP_MODE_STRICT or SECCOMP_MODE_FILTER with filters that block the
syscalls criu's parasite code needs, the dump will still fail.
Note that we disable seccomp by simply feigning that we are in mode 0. This
is a little hacky, but avoids distributing ifs throughout the code and
keeps them in this one place.
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
CC: Saied Kazemi <saied@google.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Docker requested an option, when network devices and routes are not
dumped and not restored. Instead of this Docker will call libnetwork
hook to tune netns from the setup-namespaces action.
Cc: Saied Kazemi <saied@google.com>
Tested-by: Ross Boucher <boucher@gmail.com>
Signed-off-by: Andrew Vagin <avagin@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
But keep @protobuf as a symlink: we have
this path encoded in sources. Gonna be
removed with time.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
