- 21 Apr, 2015 4 commits
-
-
Andrey Vagin authored
Currently we use a static buffer, but it is too small. Error (cr-service.c:58): Failed unpacking request: Success Error (cr-service.c:694): Can't recv request: Success data too short after length-prefix of 1217 v2: use recv instead on recvmsg Reported-by:
Ross Boucher <rboucher@gmail.com> Cc: Ross Boucher <rboucher@gmail.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Acked-by:
Ruslan Kuprieiev <rkuprieiev@cloudlinux.com> Signed-off-by:
Pavel Emelyanov <xemul@parallels.com>
-
Cyrill Gorcunov authored
Original message from Tycho: This might be a slightly controversial change since it always causes crtools.h to be rebuilt, which may be annoying. However, right now version.h is only generated on the initial git build and never again touched, which is also incorrect. We could potentially do something fancy by monitoring .git/HEAD for changes, but since it may not always exist if building from a tarball, it is a little sticky. CC: Andersen <tycho.andersen@canonical.com> CC: Pavel Emelyanov <xemul@parallels.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Acked-by:
Tycho Andersen <tycho.andersen@canonical.com> Signed-off-by:
-
Cyrill Gorcunov authored
If symlink is present the test run fails with "already exist" message. Lets make the link unconditional, this is fine. Signed-off-by:
Andrey Vagin <avagin@parallels.com> Signed-off-by:
-
Cyrill Gorcunov authored
Looks like compiler can't encode wide variants of memory copying and uses only xmm registers in 32bit mode. Lets drio i386 from here for a while. Signed-off-by:
-
- 16 Apr, 2015 4 commits
-
-
Tycho Andersen authored
`git describe` outputs slightly more useful git version info: v1.5-132-ga10f39e The motivation for this is that we'd like to begin enforcing criu version in liblxc, but we'd like to enable people to use the git version of 1.6 (since that has stuff like --ext-mount-map auto), which reports its version as 1.5 but doesn't tell us the patchlevel as git describe does. Signed-off-by:
-
Tycho Andersen authored
Andrey reported this issue and it took me a while to figure out exactly what might cause it. I think the comment describes it accurately, as with that example I end up with mountinfo on the host like: 47 23 253:1 /root/bind1/subdir /root/bind2 rw,relatime shared:1 - ext4 /dev/disk/by-uuid/6c5a78e0-95fa-49a8-aa91-a8093d295e58 rw,data=ordered 48 23 253:1 /root/bind1 /root/bind3 rw,relatime shared:1 - ext4 /dev/disk/by-uuid/6c5a78e0-95fa-49a8-aa91-a8093d295e58 rw,data=ordered Reported-by:
Andrew Vagin <avagin@odin.com> CC: Andrew Vagin <avagin@odin.com> Signed-off-by:
-
Tycho Andersen authored
If a mount like: 96 95 0:21 /cgmanager /sys/fs/cgroup/cgmanager rw master:9 - tmpfs tmpfs rw,mode=755 is present in the container and the host has a similar bind mount, e.g. 46 27 0:21 /cgmanager /sys/fs/cgroup/cgmanager rw shared:9 - tmpfs tmpfs rw,mode=755 then the best match mount's root path /and/ the target mountpoint have part of the path in them; we should cut the shared piece of the path and just concatenate the non-duplicate pieces. Reported-by:
-
Tycho Andersen authored
We only malloc() size amount of space, so we shouldn't snprintf past that. Signed-off-by:
-
- 14 Apr, 2015 15 commits
-
-
Pavel Tikhomirov authored
writing to netdev configuration at non zero offset won't be supported: ``` [ 301.431638] netns-dev wrote to accept_local when file position was not 0! This will not be supported in the future. To silence this warning, set kernel.sysctl_writes_strict = -1 ``` v2: fix compilation Sorry, please don't consider v1. Signed-off-by:
Pavel Tikhomirov <ptikhomirov@odin.com> Acked-by:
-
Oleg Nesterov authored
Currently this doesn't matter correctness-wise (with or without the previous changes), but imho collect_mntinfo() needs a cleanup. We should not return with ->mntinfo_list pointing to the freed memory on failure, even if currently this failure is fatal and nobody will ever use this pointer. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Tested-by:
-
Oleg Nesterov authored
This check was added by commit aebfabb5 "mnt: add --ext-mount-map auto option", but unless I am totally confused it actually belongs to the (already reverted) 246367e4 "add walk_all flag to walk_namespaces". Remove it. It is no longer needed and it was very unobvious. Signed-off-by:
-
Oleg Nesterov authored
We no longer need to populate ext_ns->mnt.mntinfo_list until resolve_external_mounts(). We can rely on find_ext_ns_id() which does collect_mntinfo() on demand. Signed-off-by:
-
Oleg Nesterov authored
Currently we rely on the fact that ->mntinfo_list was already collected by walk_namespaces(walk_all => true), but we are going to change this. This patch simply adds collect_mntinfo(ns) into find_ext_ns_id() if ->mntinfo_list == NULL. This is all we need for this ns_id if it was not initialized by collect_mnt_namespaces(). Signed-off-by:
-
Oleg Nesterov authored
Preparation. Extract the "search the criu's mount info" code from resolve_external_mounts() into the new simple helper, find_ext_ns_id(). Also change resolve_external_mounts() to check ext_ns == NULL rather than !opts.autodetect_ext_mounts. Cosmetic. Signed-off-by:
-
Oleg Nesterov authored
do_new_mount() clears MS_SHARED but this is not enough. It should clear all bits processed in restore_shared_options(). The patch also adds MS_UNBINDABLE to MS_CHANGE_TYPE_MASK even if it is not currently used. Just to match the kernel's do_change_type() check. Signed-off-by:
-
Pavel Emelyanov authored
Only if inventory says it's v1 -- switch to old scheme. Signed-off-by: -
Pavel Emelyanov authored
Doing it at inventory write time is too late. Other than this, inventory isn't created for pre-dump, thus this one always generates v1 images. Signed-off-by: -
Yixun Lan authored
tested under Gentoo Linux, with sys-kernel/linux-headers-3.19 installed "struct user_pt_regs" is defined at file /usr/include/asm/ptrace.h Signed-off-by:
Yixun Lan <yixun.lan@gmail.com> Reviewed-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
-
Ruslan Kuprieiev authored
Signed-off-by:
-
Pavel Emelyanov authored
These images have common magic in front of per-image one. With this we have 3 "types" of images -- inventory (head), other images, service files. The latter would be stats (not an image, just happen to be in PB format) and irmap cache (not an image again, just auxiliary thing which is in PB for convenience). Since inventory file is the first one we read on restore it's OK to set the global "new images" flag there. Dump (write) is always in new format. Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Oleg Nesterov authored
collect_mnt_namespaces() returns with ret=0 if resolve_external_mounts() fails. Signed-off-by:
-
Oleg Nesterov authored
We can simply overwrite the dot symbol right after the kernel reports it to us. Signed-off-by:
-
- 10 Apr, 2015 17 commits
-
-
Oleg Nesterov authored
resolve_source() insists on kdev_major() == 0, and this makes sense. However, at least FSTYPE__AUTO can try to use mi->source as a block device and pray it will work. [ Also bout this change from Oleg: Let me send another (last) functional change before the promised cleanups we discussed. To remind, without this patch I still can't dump/restore /home and /boot on my testing machine. --enable-fs xfs "works" in a sense that "dump" succeeds. But "restore" fails. However. Lets forget this for the moment. To me resolve_source() looks just wrong. Sure, I agree, it is not safe to blindly use mi->source if kdev_major() != 0. But this means that we should not have dumped this mountpoint, simply because we can't restore it. Yes, currently this works because fstypes[] contains only the diskless filesystems, but still. So this probably needs more cleanups too, and this patch doesn't make this logic look better. To me, we should do something like static char *resolve_source(struct mount_info *mi) { if (kdev_major(mi->s_dev) == 0) /* * Anonymous block device. Kernel creates them for * diskless mounts. */ return mi->source; if (mi->fstype->code != FSTYPE__AUTO) { pr_err("OOPS! something is wrong!!!\n"); return NULL; } // OK, this is FSTYPE__AUTO, it should "just work" // by definition. Or the user should blame himself. struct stat st; if (stat(mi->source, &st) || !S_ISBLK(st.st_mode) || major(st.st_rdev) != kdev_major(mi->s_dev) || minor(st.st_rdev) != kdev_minor(mi->s_dev)) pr_warn("Hmm, can't verify blkdev. Lets see if mount will work...\n"); return mi->source; } But this patch only does a minimal change to make FSTYPE__AUTO work with blkdev. ] Signed-off-by: -
Pavel Emelyanov authored
It mostly reuses the infrastructure for plugin testing. Signed-off-by: -
Pavel Emelyanov authored
The existing set of shell scripts do hard-to-debug things and mess with the root filesystem. We can make it better. First, not to play with the system / the process that will be run in a new mount namespace is statically compiled .c file. And this "init" does a very simple thing -- waits for SIGTERM and check that the given filepath contains the given string. Second, the namespace's root will be some subdir, instead of system / bind-mount-ed into a subdir. This makes it easier to keep things together and makes 100% sure the external bind mount cannot be accessed by custom path. Signed-off-by: -
Tycho Andersen authored
Signed-off-by:
-
Tycho Andersen authored
Signed-off-by:
-
Tycho Andersen authored
This option enables external (slave) bind mounts to be resolved. v2: don't always assume that when the master id matches, the mounts match Signed-off-by:
-
Tycho Andersen authored
With this flag, external shared bind mounts are attempted to be resolved automatically. v2: don't always assume when the sharing matches that the mount matches Signed-off-by:
-
Tycho Andersen authored
When this option is specified, if an external (private) bind mount is not specified by --ext-mount-map KEY:VAL then it is attempted to be resolved automatically. v2: introduce find_best_external_match, which looks for the best match based on sharing/slave ids; don't try to resolve fsroot_mounted() mountpoints v3: get rid of really_collect_self_mounts v4: get rid of fsroot_mounted() check when autodetecting external mounts Signed-off-by: -
Oleg Nesterov authored
Finally add --enable-fs option to specify the comma separated list of filesystem names which should be treated as FSTYPE_AUTO. Note: obviously this option is not safe, use at your own risk. "dump" will always succeed if the mntpoint is auto, but "restore" can fail or do something wrong if mount(src, mountpoint, flags, options) can not actually "just work" as FSTYPE_AUTO logic expects. Signed-off-by:
-
Oleg Nesterov authored
Add the new mnt_entry->fsname member and change dump_one_mountpoint() to save pm->fstype->name if fstype == FSTYPE__AUTO. Change collect_mnt_from_image() to pass this ->fsname to decode_fstype() which falls back to __find_fstype_by_name(fsname, true) if FSTYPE__AUTO. Signed-off-by:
-
Oleg Nesterov authored
Simple preparation to simplify the review of the next patch. Turn find_fstype_by_name(name) into __find_fstype_by_name(name, force_auto) and reimplement find_fstype_by_name() as a trivial wrapper on top. This allows "restore" to specify that this particular fsname was treated as FSTYPE__AUTO by "dump". Signed-off-by:
-
Oleg Nesterov authored
The comment in find_fstype_by_name() says: just mounting anything is wrong and this is true in general, but: almost every fs has its own features this is not true in a sense that a lot of supported filesystems do not need any special processing: FSTYPE__PROC, FSTYPE__SYSFS, and more. More importantly, this logic does not allow to spicify from the command line that (say) currently unsupported hugetlbfs can "just work", do_new_mount() should only pass the right name/options. This patch adds the new FSTYPE__AUTO code, find_fstype_by_name(name) adds the new entry if fsname_is_auto(name) returns true. We do not care that different fstype's can have the same FSTYPE__AUTO code, fstype->code has no meaning unless we need to do something special with this fs, but in this case it should not be FSTYPE__AUTO by definition. Note: currently find_fstype_by_name() just returns true, it is obviously pointless to "dump" until we teach "restore" to handle FSTYPE__AUTO. Signed-off-by:
-
Oleg Nesterov authored
Preparation. Enlarge fstypes[] to make it possible to add the new fstype's dynamically. This means ths find_fstype_by_name() and decode_fstype() need the additional ->name == NULL check to terminate the search. Also change them to start with "i == 1", we rely on the fact that fstypes[0] is FSTYPE__UNSUPPORTED anyway. Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by: -
Tycho Andersen authored
1. If a fuse connection is present, but there are no fuse mounts of that type in the mount namespace, don't refuse to dump. 2. If there are mounts of that type in the container but they are external, we're going to bind them anyway, so there's no fuse-specific things that need to be done, so it is safe to dump. v2: check that the fstype is fuse as well Signed-off-by:
-
Tycho Andersen authored
Signed-off-by:
-
Pavel Tikhomirov authored
we don't need this check as just after it we have: if (ret) break; which safely unpackes nde, and closes nlsk and img in case of error ps: sorry for inconveniences caused by my patchset Signed-off-by:
-
