Date: Sun, 21 Mar 1999 10:05:38 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brian Feldman <green@unixhelp.org> Cc: Alfred Perlstein <bright@rush.net>, "John S. Dyson" <dyson@iquest.net>, samit@usa.ltindia.com, commiters@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: rfork() Message-ID: <199903211805.KAA13805@apollo.backplane.com> References: <Pine.BSF.4.05.9903211752040.2767-100000@zone.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a
:> :stack and as soon as the rfork() returned movl newstack,%esp and whatnot,
:> :wouldn't this be a pretty simple solution?
:>
:> No, because one of the processes may overrun the stack before the other
:> one managed to return from rfork(). The child process cannot use the
:> old stack at all.
:
:Why would a simple movl be using the stack?
If you are making a subroutine *call* to the rfork() routine, where
do you think the return PC address is stored? On the stack. The
rfork() routine is going to 'ret' *after* doing the rfork syscall.
'ret' pops the stack. While this in itself is not modifying the stack,
you can still wind up with the situation where process A returns from
the rfork and then does something else which overwrites the stack before
process B has a chance to return from the rfork().
This is why, in my assembly example, I was forced to make the syscall
manually rather then call the rfork() library function.
:>
: Brian Feldman _ __ ___ ___ ___
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903211805.KAA13805>