Date: Sun, 2 Apr 2000 16:38:38 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/i386 support.s src/sys/kern init_sysent.c kern_prot.c kern_sig.c Message-ID: <200004022338.QAA51565@apollo.backplane.com> References: <200004021752.KAA13175@freefall.freebsd.org> <20000402163552.P21029@fw.wintelcom.net> <200004022312.QAA51299@apollo.backplane.com> <20000402164700.R21029@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:I did look at the code, struct proc is allocated from a zone,
:meaning it won't "go away" once allocated, there's no danger in
:dereferencing p_pptr, I don't get it.
:
:--
:-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
:"I have the heart of a child; I keep it in a jar on my desk."
What happens when the parent process exits and the system must
reassign the parent to process 1? Now think about what happens
when it occurs on one cpu while another is trying to access the
ppid.
cpu#1: cpu#2:
read p->p_pptr
indirect through to get ppid
(stalls on a cache miss plus,
due to heavy DMA, stalls on main memory)
parent process finishes
exiting, replaces p_pptr
of children, releases
struct proc.
struct proc is reused,
pid is reallocated
read completes, wrong ppid is returned
(neither the original ppid nor ppid 1
is returned).
In an SMP system you have to assume the worst case, and the worst case
is that a cpu can stall INDEFINITELY between instructions.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200004022338.QAA51565>