Greg Haerr writes:
>
> : This is essentially what I have done. The only problem with doing this is
> : that when fork() returns to the child, and the child calls exec(), the stack
> : will be modified, so when the parent comes to return from fork(), it will
> : crash, or at best do something odd.
>
> Ok. When vfork() is called, save the stack pointer in the kernel.
> Then, when the child calls exec(), more items are stored on the stack. (at
> least the return address from the exec call)
> When the parent is rescheduled, the system can reset the stack pointer
> to the value it was when vfork was called, providing that it the child
> never returned from the procedure that called fork, but instead called exec from
>there...
The problem is that the child will pull data off the stack as it returns,
and overwrite it when it calls exec. The stack state that the parent
requires in order to return from fork will have been overwritten.
>
>
>
> :
> : The scheme I am using at the moment, that of copying the bottom 100 bytes
> : of the stack for the child to use, works, but does not really offer any
> : kind of safety net. Is it fair to just accept that if a process vfork()s,
> : and does not exec or exit, but instead carries on, it may well crash?
> :
>
> It's not acceptable to carry on and crash.
I can't yet work out a way to make sure this can't happen. We could set up
some kind of timer that kills the child if it does not exec, or watch it to
see if it shrinks its stack to much and kill it then.
Al
