Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Mar 1999 20:07:16 +0000 (GMT)
From:      Brian Feldman <green@unixhelp.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
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:  <Pine.BSF.4.05.9903212004580.3722-100000@zone.syracuse.net>
In-Reply-To: <199903211958.LAA14438@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Mar 1999, Matthew Dillon wrote:

> :>     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.

What's to stop the RFSTACK from copying the stack itself into the new stack
that is located elsewhere in RAM and attached to the vm space? Actually,
rfork() would just set it in the trap frame anyway, so there would be no
extra user code to do this.

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

 Brian Feldman					  _ __  ___ ___ ___  
 green@unixhelp.org			      _ __ ___ | _ ) __|   \ 
	     http://www.freebsd.org/	 _ __ ___ ____ | _ \__ \ |) |
 FreeBSD: The Power to Serve!	   _ __ ___ ____ _____ |___/___/___/ 



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?Pine.BSF.4.05.9903212004580.3722-100000>