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

Tycho Andersen tycho.andersen at canonical.com
Fri Sep 11 13:36:19 PDT 2015


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.

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


More information about the CRIU mailing list