This as well as restore requires several steps to reach per-thread
support during dump stage
- @creds area to be fetched from the parasite is embedded into
parasite_dump_structure
- when test for task to be dumpable we no longer compare caps
because we now allow them to be different (and I renamed
proc_status_creds_eq to proc_status_creds_dumpable for this
sake)
- have to extend dump_thread_common to support dumping of
creds (we call for dump_thread_common in several places,
in particular when we need to fetch misc params we don't
need creds, here @creds option comes into the play)
- after this patch no creds-X.img file be generated anymore,
I guess we might drop it off with time from descriptors
https://jira.sw.ru/browse/PSBM-41416
v2:
- In dump_task_creds() don't mangle the call for parasite_dump_creds
and collect_lsm_profile
- PARASITE_MAX_GROUPS takes parasite_dump_thread into account because
dump_thread_common now serves two cases: for plain misc parameters
fetching and for creds as well (depending on the context)
- when test for dumpable we still require the seccomp filters
to match, they can be different and we need to support such
configuration too but not in this series
v3:
- Rip off dump_task_creds completely, together with PARASITE_CMD_DUMP_CREDS,
we dump creds unconditionally in dump_thread_common
- the group leader thread data is fetched via new
parasite_dump_thread_leader_seized helper
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
An utility to checkpoint/restore tasks. Using this tool, you can freeze a
running application (or part of it) and checkpoint it to a hard drive as a
collection of files. You can then use the files to restore and run the
application from the point it was frozen at. The distinctive feature of the CRIU
project is that it is mainly implemented in user space.
e9fc593cde