[CRIU] Checkpointing failed

[Pavel Emelyanov]

On 10/07/2014 06:44 PM, Serge Hallyn wrote:
> Quoting Pavel Emelyanov (xemul at parallels.com):
>> On 10/06/2014 09:18 PM, Thouraya TH wrote:
>>> Hello :) Thanks for answer :)
>>>
>>> root at u1:/# cd /sys/fs/fuse/connections
>>> root at u1:/sys/fs/fuse/connections# ls
>>> 30
>>> root at u1:/sys/fs/fuse/connections# cd 30/
>>> root at u1:/sys/fs/fuse/connections/30# ls
>>> abort  congestion_threshold  max_background  waiting
>>>
>>> root at u1:~# cat /proc/self/mountinfo
>>> 69 52 8:1 /var/lib/lxc/u1/rootfs / rw,relatime - ext4 /dev/disk/by-uuid/afcb71d4-c111-4988-ae14-df81b2a06181 rw,errors=remount-ro,data=ordered
>>> 70 69 0:32 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
>>> 71 69 0:33 / /sys rw,relatime - sysfs sysfs rw
>>> 72 71 0:16 / /sys/fs/fuse/connections rw,relatime - fusectl none rw
>>> 73 71 0:6 / /sys/kernel/debug rw,relatime - debugfs none rw
>>> 74 71 0:10 / /sys/kernel/security rw,relatime - securityfs none rw
>>> 75 71 0:14 /fs/pstore /sys/fs/pstore rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
>>> 53 69 0:34 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
>>> 54 69 0:34 /ptmx /dev/ptmx rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=666
>>> 55 71 0:35 / /sys/fs/cgroup rw,relatime - tmpfs none rw,size=4k,mode=755
>>> 56 69 0:36 / /run rw,nosuid,noexec,relatime - tmpfs none rw,size=97708k,mode=755
>>> 57 56 0:37 / /run/lock rw,nosuid,nodev,noexec,relatime - tmpfs none rw,size=5120k
>>> 58 56 0:38 / /run/shm rw,nosuid,nodev,relatime - tmpfs none rw
>>> 59 56 0:39 / /run/user rw,nosuid,nodev,noexec,relatime - tmpfs none rw,size=102400k,mode=755
>>
>> Ah I see. In the upstream kernel fuse and fusectl are not virtualized. So
> 
> This implies that (in openvz kernel) they are? 

Yup :)

> Url with more info?

Unfortunately I can only give you a link on openvz kernel source rpm (our
kernel guys are fixing this at the moment) :) or on the fuse code on the
previous stable kernel (but wrt fuse the newer one is the same):

http://git.openvz.org/?p=linux-2.6.18-openvz;a=blob;f=fs/fuse/inode.c;h=947c0b47610dceffecf73ff80114fce78bffa07f;hb=045f4a5fcb8c2625fe7505a8d9d4ebffd7e0d905

The interesting part is this

27 #ifndef CONFIG_VE
28 struct list_head fuse_conn_list;
29 #endif

The fuse_conn_list is no longer global but

http://git.openvz.org/?p=linux-2.6.18-openvz;a=blob;f=include/linux/ve.h;h=f9b13548443e6fa4dc25ef3efd1a615ad1b52152;hb=045f4a5fcb8c2625fe7505a8d9d4ebffd7e0d905

 #if defined(CONFIG_FUSE_FS) || defined(CONFIG_FUSE_FS_MODULE)
275         struct list_head        _fuse_conn_list;
276         struct super_block      *_fuse_control_sb;
277
278         struct file_system_type *fuse_fs_type;
279         struct file_system_type *fuse_ctl_fs_type;
280 #endif

per container, which, in OpenVZ, is described by one big
object called ve_struct.

>> the latter fs when mounted inside container reveals fuse mounts from all
>> the system. And criu fails to dump one, though none of the connections
>> seen inside fusectl belong to this container.
>>
>> Serge, Tycho, do you have any ideas what can we do about it?
> 
> Well Seth Forshee is working on patches to allow fuse mounts in user
> namespaces, but AFAIK this is an aspect he hasn't touched.  And really
> if he did he would probably set the nconnections per user-ns which wouldn't
> help in this case anyway.
> 
>> Thouraya, I think for your experiments you can just umount the fusectl fs.
>>
>> Thanks,
>> Pavel
>>
> .
>