From owner-freebsd-current Sun Mar 21 11:58:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B76FB14E93; Sun, 21 Mar 1999 11:58:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA14438; Sun, 21 Mar 1999 11:58:10 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Mar 1999 11:58:10 -0800 (PST) From: Matthew Dillon Message-Id: <199903211958.LAA14438@apollo.backplane.com> To: Brian Feldman Cc: Alfred Perlstein , "John S. Dyson" , samit@usa.ltindia.com, commiters@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: rfork() References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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 : Brian Feldman _ __ ___ ___ ___ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message