Messages in this thread | | | Date | Fri, 8 Jan 1999 17:50:16 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: Porting vfork() |
| |
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(¤t->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/
| |