From owner-freebsd-current  Sun Mar 21 10:58:15 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 B065014EC9; Sun, 21 Mar 1999 10:58:12 -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 SAA03148;
	Sun, 21 Mar 1999 18:57:01 GMT
	(envelope-from green@unixhelp.org)
Date: Sun, 21 Mar 1999 18:57:01 +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: <199903211805.KAA13805@apollo.backplane.com>
Message-ID: <Pine.BSF.4.05.9903211855540.3128-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:

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

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?

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

 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