From owner-freebsd-threads@FreeBSD.ORG Thu May 20 04:15:41 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0984B16A4CF; Thu, 20 May 2004 04:15:41 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF06C43D49; Thu, 20 May 2004 04:15:40 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i4KBFaRi085149; Thu, 20 May 2004 04:15:37 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <40AC92FF.804@freebsd.org> Date: Thu, 20 May 2004 19:14:07 +0800 From: David Xu User-Agent: Mozilla Thunderbird 0.5 (X11/20040503) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Robbins References: <20040520061142.GA3493@cat.robbins.dropbear.id.au> In-Reply-To: <20040520061142.GA3493@cat.robbins.dropbear.id.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org cc: Julian Elischer Subject: Re: execve() and KSE X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 11:15:41 -0000 Tim Robbins wrote: > On Thu, May 20, 2004 at 01:16:15AM -0400, Daniel Eischen wrote: > > >>On Wed, 19 May 2004, Julian Elischer wrote: >> >> >>>What is supposed to happen is that all the execve should stall awaiting >>>all the other kernel threads to abort/suicide and then it should proceed >>>with the execve as per normal. >>>it is possible this doesn't work right.. I haven't tried ti for a LONG >>>time.. >> >>The program is bogus also. First, you can't pass NULL to >>pthread_cond_wait() -- check the return values. Second, >>you can't join to a thread that has done an exec() -- >>the whole process has exec'd. I think you need to do >>this the old fashioned way (fork, exec, wait for child, >>etc). > > > The call to pthread_cond_wait() with a NULL mutex argument was a mistake > but the join was intentional. However, I'm not interested in the program; > I'm more interested in the way the kernel handles the execve() call > (and the general robustness of KSE heading up to 5.3-STABLE.) > > The following patch makes the program do what I would expect: exit, instead > of getting stuck in the "running" state. It clears the P_SINGLE_EXIT and > TDF_SA flags after clearing P_SA in kern_execve(). Without this, the flags > are still set in the single-threaded process that comes out the other > side of the execve() syscall, and it ends up getting stuck in > sched_switch <- choosethread <- thread_exit <- thread_user_enter <- > trap <- calltrap. > > (FWIW: there seems to be another nearby bug: the mtx_unlock(&Giant) call > in the kern_execve() ERESTART case may be erroneous, since I can't see > where Giant is acquired.) > > ==== //depot/user/tjr/freebsd-tjr/src/sys/kern/kern_exec.c#19 - /home/tim/p4/src/sys/kern/kern_exec.c ==== > @@ -264,7 +264,8 @@ > * If we get here all other threads are dead, > * so unset the associated flags and lose KSE mode. > */ > - p->p_flag &= ~P_SA; > + p->p_flag &= ~(P_SA|P_SINGLE_EXIT); > + p->p_singlethread->td_flags &= ~TDF_SA; > td->td_mailbox = NULL; > thread_single_end(); > } > > Good catch, I'd like to see P_SINGLE_EXIT is cleared in kern_thread.c::thread_single_end(). > Tim David Xu