Quoting Oren Laadan ([email protected]): > > > Serge E. Hallyn wrote: > > Quoting Oren Laadan ([email protected]): > >> The task address space (task->mm) may be shared between processes if > >> CLONE_VM is used, and particularly among threads. Accordingly, treat > >> 'task->mm' as a shared object: during checkpoint check against the > >> objhash and only dump the contents if seen for the first time. During > >> restart, likewise, only restore if it's a new instance, otherwise use > >> the one already registered in the objhash. > >> > >> Signed-off-by: Oren Laadan <[email protected]> > > > > Cool. > > > > Acked-by: Serge Hallyn <[email protected]> > > > > Although: > > > >> + /* if the mm's objref is in the objhash, use that instance */ > >> + mm = cr_obj_get_by_ref(ctx, hh->objref, CR_OBJ_MM); > >> + if (IS_ERR(mm)) { > >> + ret = PTR_ERR(mm); > >> + goto out; > >> + } > >> > >> + if (mm) { > >> + if (mm != current->mm) { > > > > In what twisted world could mm == current->mm at restart? > > Tasks are re-created in user space, and so are threads. So threads will > already have their 'mm' set correctly.
Doesn't that assume that one task will complete sys_restart() before it does clone(CLONE_VM)? Else sure, the threads will already share an mm, but it'll be the wrong one? And I didn't think the sys_restart() synchronization supported that order. (I realize I'm probably completely misunderstanding, and sounding like an idiot...) And since OpenVZ has never re-sent their patch to do task creation in kernel-space on top of your set, I won't even debate about re-creation in user-space being certain :) -serge _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
