Date: Tue, 16 Sep 1997 01:35:08 -0700 From: Jason Thorpe <thorpej@nas.nasa.gov> To: Simon Shapiro <Shimon@i-connect.net> Cc: Julian Elischer <julian@whistle.com>, freebsd-hackers@freebsd.org Subject: Re: What is wrong with this snipet? Message-ID: <199709160835.BAA28756@lestat.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
On Tue, 16 Sep 1997 01:20:56 -0700 (PDT) Simon Shapiro <Shimon@i-Connect.Net> wrote: > >From my naive point of view, what is less than very useful is the fact that > one process exiting blows up the other which is not. One would think that > since all processes now share the same address space, early exiters do not > take the memory with them, but leave it for the others. Um, I think people might have misunderstood what I originally pointed out about the FreeBSD rfork() ... I was merely pointing out that the RFMEM semantics were different from Plan 9's (my interpretation of the Plan 9 semantics are that only text/data/bss are shared, not the entire address space, which we could do in a similar fashion by using a sharing map), and that when the child executes a "return" statement, he's going to smash the stack of the parent, or vice versa. When the child exits (actually, _exits :-) or exec's, the only thing that happens to the vmspace is that the refcount drops. It's worth noting that even with a Real vfork(2), the danger of stack smashing (and the restriction that one must use _exit(), not exit()) exists. That's why all of the special vfork system call stubs exist - they pop the return-address early (before the actual system call), save it in a register, and then return to the caller via an indirect jump (through the function pointer saved in the register). This works because vfork() takes no arguments (if it did, the kernel's syscall gate would look for the argument in the wrong place, since the RA has been popped). Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709160835.BAA28756>