[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