From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 14 09:17:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 071051065672 for ; Tue, 14 Aug 2012 09:17:18 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C78938FC16; Tue, 14 Aug 2012 09:17:17 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7E9GrcI003464; Tue, 14 Aug 2012 09:17:06 GMT (envelope-from davidxu@freebsd.org) Message-ID: <502A1788.9090702@freebsd.org> Date: Tue, 14 Aug 2012 17:16:56 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Konstantin Belousov References: <20120730102408.GA19983@stack.nl> <20120730105303.GU2676@deviant.kiev.zoral.com.ua> <20120805215432.GA28704@stack.nl> <20120806082535.GI2676@deviant.kiev.zoral.com.ua> <20120809105648.GA79814@stack.nl> <5029D727.2090105@freebsd.org> <20120814081830.GA5883@deviant.kiev.zoral.com.ua> In-Reply-To: <20120814081830.GA5883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: system() using vfork() or posix_spawn() and libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:17:18 -0000 On 2012/08/14 16:18, Konstantin Belousov wrote: > On Tue, Aug 14, 2012 at 12:42:15PM +0800, David Xu wrote: >> I simply duplicated idea from OpenSolaris, here is my patch >> which has similar feature as your patch, and it also tries to >> prevent vforked child from corrupting parent's data: >> http://people.freebsd.org/~davidxu/patch/libthr-vfork.diff > You shall not return from vfork() frame in the child. Otherwise, the > same frame is appears to be destroyed in parent, and parent dies. More > often on !x86, but right combination of events on x86 is deadly too. > If pid or curthread local variables are spilled into stack save area, > then child will override them, and e.g. parent could see pid == 0, > returning it to caller. > > This was the reason why I went to asm wrapper for vfork. > OK. > Also, it seems that in mt process, malloc and rtld are still broken, > or am I missing something ? I will not call it as broken, malloc and rtld are working properly. vfork is not a normal function, for MT process, fork() is even very special too. POSIX says a lot about multi-threaded: http://pubs.opengroup.org/onlinepubs/000095399/functions/fork.html I quoted some POSIX document here: > A process shall be created with a single thread. If a multi-threaded > process calls fork(), the new process shall contain a replica of the > calling thread and its entire address space, possibly including the > states of mutexes and other resources. Consequently, to avoid errors, > the child process may only execute async-signal-safe operations until > such time as one of the exec functions is called. [THR] Fork > handlers may be established by means of the pthread_atfork() function > in order to maintain application invariants across fork() calls. This means child process should only do very simple things, and quickly call execv(). For mt process, fork() is already a very complicated problem, one of problems I still remembered is that when fork() is called in signal handler, should the thread library execute pthread_atfork handler ? if it should do, but none of lock is async-signal safe, though our internal rwlock allows to be used in signal handler, but it is not supported by POSIX. Also are those atfork handler prepared to be executed in signal handler ? it is undefined. POSIX had opened a door here. Above is one of complicated problem, the vfork is even more restrictive than fork(). If it is possible, I would avoid such a complicated problem which vfork() would cause. Regards, David Xu