When we have opened and unlinked chr or blk device, we
shouls also take care of their rdev value. Thus -- new
field in image and some new steps on dump and restore.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When opening a reg file on restore -- check that the file size we
opened matches the on we saw on dump. This is not bullet-proof protection,
but is helpful to protect against FS updates between dump/restore.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This fixes the support for fifo-s in mount namespaces and
makes it easier to control the correct open_path() usage in
the future.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The nsid lookup will search for mount in case mnt_id
is given. No need to do it twice (the 2nd time for
sanity check).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This is more logical -- we should remap file in namespace,
not in pid. Also this would help to clean the code further.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Nowadays this routine is mainly used for getting an
fd, rather than keeping one for future reference.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This patch removes the global mntinfo_tree and collect_mount_info where
it was constructed. The mntinfo list is filled from dump_mnt_ns,
rst_collect_local_mntns, collect_mnt_namespaces and read_mnt_ns_img.
A mountinfo entry contains a reference on a proper ns_id entry, so
we cau use mnt_id to look up a proper mount namespace.
v2: remove trash after rebasing.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's already used for dumping files and it will be used for restoring,
so it should be service fd to avoid intersection with restored
descriptors.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Fixes two issues with efe594f8f421 "criu: fix filemap open permissions":
- Permissions on files with both open file descriptors and mappings.
- Restore compatibility with dumps created by previous versions of criu.
Signed-off-by: Jamie Liu <jamieliu@google.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
An mmaped file is opened O_RDONLY or O_RDWR depending on the permissions
on the first vma dump_task_mm() encounters mapping that file. This
causes two problems:
1. If a file has multiple MAP_SHARED mappings, some of which are
read-only and some of which are read-write, and the first encountered
mapping happens to be read-only, the file will be opened O_RDONLY
during restore, and mmap(PROT_WRITE) will fail with EACCES, causing
the restore to fail.
2. If a file is opened read-write and mapped read-only, it will be
opened O_RDONLY during restore, so restore will succeed, but
mprotect(PROT_WRITE) on the read-only mapping after restore will
fail.
To fix both of these, record open flags per-vma based on the presence of
VM_MAYWRITE in smaps.
Signed-off-by: Jamie Liu <jamieliu@google.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When live-migrating a container on NFS the link-remap cannot
create original file on target machine, since the file name
is still visible -- source CT is alive. The proper fix would
be to move file aside, then create link, then move original
file back, but since NFS changes file name anyway, we just
do the same -- generate another name for link.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Same for previous patch with vmas -- we do it on collect and
on real open. Just put the pointer on fifo_info structure.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We do it first -- on collect, second -- on restore. The
2nd lookup is excessive, we can put fd pointer on vm_area
at lookup and reuse one later.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
With new remap refcount users will get the counter
eventually as they appear.
Reported-by: Andrew Vagin <avagin@parallels.com> via Jenkins
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If a file mmaped or pointed by exe link is unlinked, we will
generate a ghost file for it. On restore the ghost file will
be created with the users counter 1 and the very first open
(e.g. for mmap) will unlink the file.
Handle this by bumping up user counter for every mapping
pointing on the file.
This appeared after previous patches that packed the reg-files
image. Before it each vma and exe link created separate entry
in the reg-files image.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We cannot distinguish ghost files from linked-remap for NFS.
Link count is never 0 on such files and any positive value of
it doesn't mean, that the file will stay in place after we
terminate all tasks we dump -- they can hold multiple unlinked
links on the same file and they all will be delayed-unlined.
Checkinf file path doesn't work as well -- silly-rename files
remain visible by VFS, though they shouldn't :(
Fortunatelly, NFS allows creation of additional likns on such
files, so we just create linked remap for such files.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
If the former file had a path long enough to be near
PATH_MAX limit, sprintf'ing link_remap.%d here might
overrun the limit. Use snprintf instead.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Remove whitespace at EOL (found by git grep ' $')
(the character before $ is real tab, typed in shell using Ctrl+V Tab)
To people using vim, I'd suggest adding the following code to ~/.vimrc:
let c_space_errors = 1
highlight FormatError ctermbg=darkred guibg=darkred
match FormatError /\s\+$\|\ \+\t\|\%80v.\|\ \{8\}/
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Here is nothing interecting. If a file can't be dumped by criu,
plugins are called. If one of plugins knows how to dump the file,
the file entry is marked as need_callback. On restore if we see
this mark, we execute plugins for restoring the file.
v2: Callbacks are called for all files, which are not supported by CRIU.
v3: Call plugins for a file instead of file descriptor. A few file
descriptors can be associated with one file.
v4: A file descriptor is opened in a callback. It's required for
restoring anon vmas.
v5: Add a separate type for unsupported files
v6: define FD_TYPES__UNSUPP
v7: s/unsupp/ext (external)
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Remove space before tab characters.
Found by git grep ' ' (Space, Ctrl-V, Tab in shell).
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
When dumping a ghost file we put real device in its header,
not the (btrfs) virtual one. This is done since we put real
devices into fsnotify images (we get them from proc). That
said on fsnotify ghost restore we don't need to do path
resolution, just devices compare.
And one more thing. When dumping device for ghost file for
_non_ btrfs case we have to convert stat dev_t into kernel
dev_t as all the other places in criu manipulate the latter
ones.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Instead of scanning btrfs subvolumes (which can be even unaccessbile
if mount point lays on directory instead of subvolume itself) we use
path resolving feature here -- once we need to figure out if some
device number need to be altered up to mount point (as we know stat()
called on subvolume returns st_dev for subvolume itself, but not
one that associated with a superblock and shown in /proc/self/mountinfo
output).
This as well implies that we need to check if device number for ghost
files are to be updated to match mountinfo, thus we use phys_stat_resolve_dev
helper here.
After this patch the previously merged btrfs engine is no longer needed
(at least it seems so) and can be dropped.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In case if ghost file is on BTRFS subvolume we should not fail
but test if there is a match.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In case if checkpoint is failed or -R option passed
we need to remove link remap files created during
dump procedure.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There's ... a number of places where we want to do something
with /proc/self/fd/%d path. Each time we guess buffer size
that is enough for this. Make standard constant for this and
save some space on stack and drop args for some functions.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
These contain linkage between number, data type and routines
for pb messages we write/read to/from image files. Most of them
have simple number-type-routines mapping, so introduce a generating
script for that.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's not quite clean, but on dump non-seekable files dump 0xff...ff into
64-bit pos field of the image. Thus on restore we'd face an error in the
do_open_reg. In order not to have separate helper for non-seekable files
just skip the position restore for such.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
