Messages in this thread | | | Subject | vfork specs | From | Ulrich Drepper <> | Date | 15 Jan 1999 09:56:28 -0800 |
| |
Implementing the vfork syscall wrapper in the libc apparently provides some problems. To find a solution it's necessary to get a specification of vfork, or at least make one up for Linux.
The problem is this: the vfork'ed process using the same VM as the initial process. Assume the following code for now:
void bar () { if ((pid = vfork ()) == 0) foo (0); else if (pid == -1) ...error...
When calling the vfork wrapper we have the following stack layout:
...something... return address bar after vfork call
Now the child returns from the vfork call and calls `foo' with the resulting layout:
...something... 0 return address bar after foo call
May `foo' then exit and so the parent process starts and it sees the return address 0 (zero) which was pushed as a parameter for `foo'.
This certainly is a situation we have to deal with and make sure that the return address from the `vfork' syscall stays valid. But this is only have of the story. It gets complicated if the use of the vfork is not restricted. Assume this:
void bar () { pid_t p = baz (); if (p == 0) foo (0); } pid_t baz () { return vfork (); }
Now the stack layout when reachine the syscall wrapper is
...something... return address bar after baz call return address baz after vfork call
At the time the function foo is called the stack layout is
...something... 0 return address bar after foo call
I.e., we are again f*cked. This can of course be repeated for arbitrary depths of function calls.
So the question is: does the vfork interface on other platforms restricts the use of vfork to situations like the first example and disallows the second one (or even deeper nestings)? I think this is what the Solaris man page says.
-- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------
- 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/
| |