execve() and KSE

[Tim Robbins]

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();
 	}


Tim