Date: Sun, 21 Mar 1999 11:58:10 -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: <199903211958.LAA14438@apollo.backplane.com> References: <Pine.BSF.4.05.9903211855540.3128-100000@zone.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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().
:
:Why does it matter if something munges the stack in proc A though before
:proc B returns since proc B is going to immediately switch over to a new
:stack?
The return address for the procedure call is on the stack. If something
munges the stack after the physical rfork occurs but before both processes
can return from the rfork() clib function, then one of the processes
attempting to return will pop a bogus return address and seg fault.
-Matt
Matthew Dillon
<dillon@backplane.com>
: Brian Feldman _ __ ___ ___ ___
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?199903211958.LAA14438>