Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 May 2004 19:14:07 +0800
From:      David Xu <davidxu@freebsd.org>
To:        Tim Robbins <tjr@freebsd.org>
Cc:        Julian Elischer <julian@elischer.org>
Subject:   Re: execve() and KSE
Message-ID:  <40AC92FF.804@freebsd.org>
In-Reply-To: <20040520061142.GA3493@cat.robbins.dropbear.id.au>
References:  <Pine.BSF.4.21.0405192113200.11004-100000@InterJet.elischer.org> <Pine.GSO.4.10.10405200111150.20696-100000@pcnet5.pcnet.com> <20040520061142.GA3493@cat.robbins.dropbear.id.au>

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



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