svn commit: r296501 - head/sys/compat/linux

[Chagin Dmitry]

On Tue, Mar 08, 2016 at 04:52:33PM +0100, Mateusz Guzik wrote:
> On Tue, Mar 08, 2016 at 03:08:22PM +0000, Dmitry Chagin wrote:
> > Author: dchagin
> > Date: Tue Mar  8 15:08:22 2016
> > New Revision: 296501
> > URL: https://svnweb.freebsd.org/changeset/base/296501
> > 
> > Log:
> >   Link the newly created process to the corresponding parent as
> >   if CLONE_PARENT is set, then the parent of the new process will
> >   be the same as that of the calling process.
> >   
> >   MFC after:	1 week
> > 
> > Modified:
> >   head/sys/compat/linux/linux_fork.c
> > 
> > Modified: head/sys/compat/linux/linux_fork.c
> > ==============================================================================
> > --- head/sys/compat/linux/linux_fork.c	Tue Mar  8 14:55:50 2016	(r296500)
> > +++ head/sys/compat/linux/linux_fork.c	Tue Mar  8 15:08:22 2016	(r296501)
> > @@ -222,6 +222,18 @@ linux_clone_proc(struct thread *td, stru
> >  	if (args->flags & LINUX_CLONE_SETTLS)
> >  		linux_set_cloned_tls(td2, args->tls);
> >  
> > +	/*
> > +	 * If CLONE_PARENT is set, then the parent of the new process will be 
> > +	 * the same as that of the calling process.
> > +	 */
> > +	if (args->flags & LINUX_CLONE_PARENT) {
> > +		sx_xlock(&proctree_lock);
> > +		PROC_LOCK(p2);
> > +		proc_reparent(p2, td->td_proc->p_pptr);
> > +		PROC_UNLOCK(p2);
> > +		sx_xunlock(&proctree_lock);
> > +	}
> > +
> >  #ifdef DEBUG
> >  	if (ldebug(clone))
> >  		printf(LMSG("clone: successful rfork to %d, "
> > 
> 
> What is the reason to support this flag? It is questionable at best
> since it gives surprise children to unsuspecting processes.
>
mostly due to the same reason that a Linux do. if this flag is set then
calling process does not expect signal when the child terminates.
 
> The patch looks wrong. By the time this is executed the child could have
> been attached to with ptrace, which reparents it.
> 
> If the flag really needs to be supported (why?), it should make sure the
> parent is a linux process and also should fix the race with ptrace.
> Maybe a "fork completed" or something of the sort flag could be
> introduced, or PRS_NEW state modified later.
> 
hmm, I'll think about it, thanks