[CRIU] Android port

[Pavel Emelyanov]

On 06/05/2015 12:20 AM, CRIU criu wrote:
> lookup_nsid_by_mnt_id() fails for fd = 0
> (00.314250) Error (files-reg.c:817): Unable to look up the 10 mount
> 
> (00.311795) 1915 fdinfo 0: pos: 0x               0 flags:           400002/0
> 
> Output from lsof | grep 1915
> 1915     u0_a37    *0*       ???                ???       ???        ???*/dev/null*
> 1915     u0_a37   *1*       ???                ???       ???        ???*/dev/null*
> 1915     u0_a37    *2*       ???                ???       ???        ???*/dev/null*
> 
> # cat /proc/1915/fdinfo/0                                  
> pos:    0
> flags:    0400002
> mnt_id:    10
> 
> 
> However, I don't see mnt_id = 0xa (10) from mountinfo. Am I missing something? Any idea where to look for this?

This happens when the file is opened in another mount namespace. Typically this is
done like this

fd = open("/dev/null");
unshare(CLONE_NEWNS);

After this the fd would point to a file from former mount namespace. It's another
example of a resource leaking outside of what you dump.

-- Pavel

> (00.043094)     type rootfs source rootfs mnt_id 0x19 s_dev 0x2 / @ ./ flags 0x1 options size=256340k,nr_inodes=64085
> (00.043398)     type tmpfs source tmpfs mnt_id 0x1a s_dev 0xb / @ ./dev flags 0x200002 options mode=755
> (00.044501)     type devpts source devpts mnt_id 0x1b s_dev 0xa / @ ./dev/pts flags 0x200000 options mode=600,ptmxmode=000
> (00.045000)     type cgroup source none mnt_id 0x1c s_dev 0xf / @ ./dev/memcg flags 0x200000 options memory
> (00.045162)     type cgroup source none mnt_id 0x1d s_dev 0x12 / @ ./dev/cpuctl flags 0x200000 options cpu
> (00.045340)     type proc source proc mnt_id 0x1e s_dev 0x4 / @ ./proc flags 0x200000 options
> (00.045488)     type sysfs source sysfs mnt_id 0x1f s_dev 0xc / @ ./sys flags 0x200000 options
> (00.045699)     type debugfs source debugfs mnt_id 0x20 s_dev 0x6 / @ ./sys/kernel/debug flags 0x200000 options
> (00.045871)     type tmpfs source none mnt_id 0x21 s_dev 0xe / @ ./sys/fs/cgroup flags 0x200000 options mode=750,gid=1000
> (00.046066)     type cgroup source none mnt_id 0x22 s_dev 0xf / @ ./sys/fs/cgroup/memory flags 0x200000 options memory
> (00.046216)     type cgroup source none mnt_id 0x23 s_dev 0xd / @ ./acct flags 0x200000 options cpuacct
> (00.046418)     type tmpfs source tmpfs mnt_id 0x24 s_dev 0x10 / @ ./mnt/asec flags 0x200000 options mode=755,gid=1000
> (00.046616)     type tmpfs source tmpfs mnt_id 0x25 s_dev 0x11 / @ ./mnt/obb flags 0x200000 options mode=755,gid=1000
> (00.046794)     type ext4 source /dev/block/mtdblock0 mnt_id 0x26 s_dev 0x1f00000 / @ ./system flags 0x200001 options data=ordered
> (00.046980)     type ext4 source /dev/block/mtdblock1 mnt_id 0x27 s_dev 0x1f00001 / @ ./data flags 0x406 options data=ordered
> (00.047146)     type ext4 source /dev/block/mtdblock2 mnt_id 0x28 s_dev 0x1f00002 / @ ./cache flags 0x406 options data=ordered
> 
> On Thu, Jun 4, 2015 at 2:11 PM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>> wrote:
> 
>     On 06/04/2015 11:46 PM, CRIU criu wrote:
>     > On Thu, Jun 4, 2015 at 1:23 PM, Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com> <mailto:xemul at parallels.com <mailto:xemul at parallels.com>>> wrote:
>     >
>     >     On 06/04/2015 05:35 PM, CRIU criu wrote:
>     >     > Can CRIU be used to checkpoint/restore a single process and not a process tree?
>     >
>     >     Without a patch -- no, it always scans for the process subtree starting from the
>     >     pid given.
>     >
>     >
>     > Is there a patch already to do this?
> 
>     Well, nope :) We used to have the ability to dump and restore a single process with
>     CRIU, but removed one way before v1.0 was released.
> 
>     >     > I keep hitting this error message:
>     >     >
>     >     >     if (item->sid == 0) {
>     >     >
>     >     >         pr_err("A session leader of %d(%d) is outside of its pid namespace\n",
>     >     >
>     >     >             item->pid.real, item->pid.virt);
>     >     >
>     >     >         goto err_cure;
>     >     >
>     >     >     }
>     >
>     >     But it's not about dumping a single task or a subtree, it's about the resources
>     >     leaking outside of what you dump :)
>     >
>     >
>     > I agree. However, an Android process behaves very differently from a regular linux process
>     > - some of the resources are released when a process goes in the background so we don't have
>     > to dump everything because released resources will be reacquired upon resume (restore) when
>     > brought into foreground again. That means the way we resume will change for Android. I will
>     > fix this as I go along.
> 
>     I see. Well, if there's a case to relax some restrictions CRIU impose on the linkage of
>     resources tasks have, then the patch would be welcome :)
> 
>     > I also see "Uncollected sockets! Will probably fail later." error message. What does it mean?
> 
>     Ah, never mind. It's just a warning, that not all the sockets were collected and that
>     dump _may_ fail if uncollected socket is in use by the task(s) you dump. BTW, there's
>     BUG in this message, I'll fix one soon.
> 
>     > Thanks for your help!
> 
>     You're always welcome!
> 
>     -- Pavel
> 
>