Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Mar 2016 16:52:33 +0100
From:      Mateusz Guzik <mjguzik@gmail.com>
To:        Dmitry Chagin <dchagin@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r296501 - head/sys/compat/linux
Message-ID:  <20160308155233.GA7447@dft-labs.eu>
In-Reply-To: <201603081508.u28F8Mtq005783@repo.freebsd.org>
References:  <201603081508.u28F8Mtq005783@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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.

-- 
Mateusz Guzik <mjguzik gmail.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160308155233.GA7447>