Re: Porting vfork()

Kenneth Albanowski (kjahds@kjahds.com)
Fri, 8 Jan 1999 17:50:16 -0500 (EST)

On Fri, 8 Jan 1999, Perry Harrington wrote:

> The parent doesn't listen to SIGKILL, SIGKILL it an unmaskable signal that is handled
> by the process management system of the kernel.

Sort of. The parent chooses whether to listen to any signals (including
SIGKILL) by using sleep_on() or sleep_on_interruptible(). If the former,
even SIGKILL won't interrupt the process.

> If you issue a SIGKILL to the parent, it'll take care of the children
> (clone() creates a dependency which causes the kernel to kill processes
> clone()d, if I'm right).

I'm not aware of any such dependancy. Nothing should break in that case,
yes, but I don't see why the child will die when the parent does. If you
mix in process groups, sure, but that's another matter.

> Attached is my patch, the explanations and such should hit LK sometime, when the first
> rev goes through.

One comment:

> diff -u --recursive linux.vanilla/fs/exec.c linux/fs/exec.c
> --- linux.vanilla/fs/exec.c Sun Nov 15 09:52:27 1998
> +++ linux/fs/exec.c Fri Jan 8 10:58:07 1999
> @@ -808,6 +808,9 @@
> int retval;
> int i;
>
> + /* vfork semantics say wakeup on exec or exit */
> + wake_up(&current->p_opptr->vfork_sleep);
> +
> bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
> for (i=0 ; i<MAX_ARG_PAGES ; i++) /* clear page-table */
> bprm.page[i] = 0;

No, this is in the wrong place. You don't want to wake the parent up until
the execve has succeeded. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/