Re: [RFC v14-rc3][PATCH 33/36] Support for share memory address spaces

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> 
> 
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> >> 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 <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
> > 
> > Cool.
> > 
> > Acked-by: Serge Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> > 
> > 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