From owner-freebsd-current  Sun Mar 21 12: 8:28 1999
Delivered-To: freebsd-current@freebsd.org
Received: from zone.syracuse.net (zone.syracuse.net [209.2.141.6])
	by hub.freebsd.org (Postfix) with ESMTP
	id F104114D1E; Sun, 21 Mar 1999 12:08:25 -0800 (PST)
	(envelope-from green@unixhelp.org)
Received: from localhost (green@localhost)
	by zone.syracuse.net (8.9.2/8.9.2) with ESMTP id UAA03732;
	Sun, 21 Mar 1999 20:07:16 GMT
	(envelope-from green@unixhelp.org)
Date: Sun, 21 Mar 1999 20:07:16 +0000 (GMT)
From: Brian Feldman <green@unixhelp.org>
X-Sender: green@zone.syracuse.net
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()
In-Reply-To: <199903211958.LAA14438@apollo.backplane.com>
Message-ID: <Pine.BSF.4.05.9903212004580.3722-100000@zone.syracuse.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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