[CRIU] Sync TODO-s for mount.c work
Pavel Emelyanov
xemul at parallels.com
Mon Apr 27 03:57:10 PDT 2015
On 04/25/2015 07:12 PM, Oleg Nesterov wrote:
> On 04/21, Pavel Emelyanov wrote:
>>
>> This is just to make sure I properly track what's going on with mount.c :)
>
> And let me report another problem, just for record. Sorry if this
> was already discussed or documented somewhere. And please correct
> me if I am wrong, I still do not really understand this "mount"
> magic.
>
> I do not see how CRIU can dump/restore a mount_nodev() mount, say,
> tmpfs. Yes, tmpfs_dump() and tmpfs_restore() are clever and I am
> not saying there are always wrong, but this depends on use-case.
>
> Once again, my lovely trivial example:
>
> # unshare -m
>
> # grep run /proc/self/mountinfo
> 52 26 0:18 / /run rw,nosuid,nodev shared:22 - tmpfs tmpfs rw,seclabel,mode=755
>
> # perl -e 'close STDIN; close STDOUT; close STDERR; sleep'
>
> and dump/restore works. In particular it dumps/restores /run. But
> it actually restores the "copy" of this mount and this is pointless
> in this particular case.
Sure, but from my perspective that's because /run is not detected as a clone
from some existing (host-side) mountpoint.
> CRIU doesn't have an option to change this behaviour but this is
> minor, to simplify the discussion lets suppose we want to change
> the current behaviour so /run is still "shared" after restore.
>
> How can we do this?
>
> "restore" does clean_mnt_ns(), this umounts "/run", and after that
> I don't see how we can re-mount it "correctly" without nontrivial
> setns-like hacks.
This is the case when all mountpoints are shares or slaves of some others from
the host side, is it?
-- Pavel
More information about the CRIU
mailing list