On Mon, Feb 06, 2017 at 01:40:53PM -0800, Ram Pai wrote: > On Sun, Feb 05, 2017 at 07:25:09PM -0800, Andrei Vagin wrote: > > On Sat, Feb 04, 2017 at 09:58:39AM +1300, Eric W. Biederman wrote: > > > Ram Pai <linuxram@xxxxxxxxxx> writes: > > > > > > > On Sat, Feb 04, 2017 at 07:26:20AM +1300, Eric W. Biederman wrote: > > > >> Ram Pai <linuxram@xxxxxxxxxx> writes: > > > >> > > > >> > On Fri, Feb 03, 2017 at 11:54:21PM +1300, Eric W. Biederman wrote: > > > >> >> ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > > > >> >> > > > >> >> > Ram Pai <linuxram@xxxxxxxxxx> writes: > > > >> >> > > > > >> >> >> On Sat, Jan 21, 2017 at 05:15:29PM +1300, Eric W. Biederman wrote: > > > >> >> >>> Ram Pai <linuxram@xxxxxxxxxx> writes: > > > >> >> >>> > > > >> >> >>> >> @@ -359,12 +373,24 @@ int propagate_mount_busy(struct mount *mnt, int refcnt) > > > >> >> >>> >> > ....snip.... > > > > > > A bit more than that, as it means that it requires an almost exact > > > playback of the sequence of mounts in all mount namespaces to > > > get to the point of reproducing a mount namespace. > > > > > Currently dump and restore of mount namespaces is the most complicated > > part of CRIU. The main problem is that we don't know how a tree of > > mounts was created. Mounts have two types of relationships: > > child<->parent and shared groups. Currently both this relationships > > can't be restored directly. We can not add a mount into an existing > > group, the group can be only inherited from a source mount. And we can > > not restore "tucked" mounts, which can be only appeared due to Sorry, I used a wrong term. I mean "shadow" mounts. > > propagation. > > > > Now we don't know an algorithm to dump and restore any set of mount > > points for a reqsonable time. The problem becomes more complex if we > > start thinking how to restore mount namespaces which lives in different > > user namespaces. > > > > > > This patch from Eric together with my patch https://lkml.org/lkml/2017/1/23/712 > > can solve the problem of dumping and restoring mount namespaces. > > Lets say we exposed the tucked flag for the mount in the > /proc/*/mountinfo, than there will be no need to know the history. > Its just a matter or setting that flag as part of > your new MS_SET_GROUP mount() call. right? This is right. > > Looking at the patch at https://lkml.org/lkml/2017/1/23/712, I am > guessing the CRUI dumps information from mountinfo to restore it > later. > > RP >
