From owner-svn-src-all@freebsd.org Tue Mar 8 19:36:04 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 743B4AC8EA5; Tue, 8 Mar 2016 19:36:04 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from heemeyer.club (heemeyer.club [108.61.204.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 34FB9B8F; Tue, 8 Mar 2016 19:36:03 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from chd.heemeyer.club (dchagin.static.corbina.ru [78.107.232.239]) by heemeyer.club (8.15.2/8.15.1) with ESMTPS id u28JZxoq018635 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Mar 2016 19:36:00 GMT (envelope-from dchagin@chd.heemeyer.club) X-Authentication-Warning: heemeyer.club: Host dchagin.static.corbina.ru [78.107.232.239] claimed to be chd.heemeyer.club Received: from chd.heemeyer.club (localhost [127.0.0.1]) by chd.heemeyer.club (8.15.2/8.15.1) with ESMTPS id u28JZwap070913 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Mar 2016 22:35:58 +0300 (MSK) (envelope-from dchagin@chd.heemeyer.club) Received: (from dchagin@localhost) by chd.heemeyer.club (8.15.2/8.15.2/Submit) id u28JZwtb070912; Tue, 8 Mar 2016 22:35:58 +0300 (MSK) (envelope-from dchagin) Date: Tue, 8 Mar 2016 22:35:58 +0300 From: Chagin Dmitry To: Mateusz Guzik 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: <20160308193558.GA70881@chd.heemeyer.club> References: <201603081508.u28F8Mtq005783@repo.freebsd.org> <20160308155233.GA7447@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160308155233.GA7447@dft-labs.eu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 19:36:04 -0000 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