[CRIU] c/r of tasks with currently open cgroup files

[Pavel Emelyanov]

On 09/11/2015 11:36 PM, Tycho Andersen wrote:
> Hi all,
> 
> Some tasks may want to open a cgroup directory (or file):
> 
> (00.008556) 5826 fdinfo 5: pos: 0x               0 flags:          2304000/0x1
> (00.008586) Dumping path for 5 fd via self 31 [/sys/fs/cgroup/systemd/lxc/priv]
> 
> The problem is that on restore, criu users can pass --cgroup-root=/lxc/priv2
> (or whatever) to rewrite their root cgroup paths, and this path is not created.

The --cgroup-root implicitly implies :) that tasks don't see the full paths of
cgroup files, i.e. thy live in a FS tree where /sys/fs/cgroup/anything points
to some /sys/fs/cgroup/anything/foo/ directory on host in which the tasks we
dump actually live. And putting --cgroup-root on restore means that you just
want to move tasks from /sys/.../foo into /sys/.../bar fixing the visible FS
tree accordingly (with the --ext-mount-map I suppose).

So how can this happen that task in a container sees full cgroup path?

> It seems like we can rewrite the paths of any such file to be the new cgroup
> root path. However, we can't necessarily do things like lseek, because the
> files may not have the right values yet:
> 
> * tasks: it should have the right values, because the file restore happens
>   after CR_STATE_FORKING
> * cgroup.procs: this will be wrong in case there are threads, because the
>   threads are only cloned by the restorer blob at the very end
> * special properties, e.g. cpuset.cpus: we have to fill in these before any
>   task is inserted into them so these should be ok
> * other properties: these have to be restored at the end for speed reasons, so
>   it happens after the fd restore runs
> 
> I think (?) it's probably ok that lseek won't work in most cases since it's
> unlikely normal people will be seeking around in cgroup files. Even still, if
> the application has computed a path to open on cgfs, it may have also cached
> something about that path, so if we do a --cgroup-root, that'll screw things
> up.
> 
> Should I write a patch to rewrite these file paths and hope for the best?
> What's the right course of action here?
> 
> Thanks,
> 
> Tycho
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
> .
>