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/
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/