From owner-freebsd-current  Sun Apr  2 16:38:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id A7D7D37BB7A
	for <current@FreeBSD.ORG>; Sun,  2 Apr 2000 16:38:41 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA51565;
	Sun, 2 Apr 2000 16:38:38 -0700 (PDT)
	(envelope-from dillon)
Date: Sun, 2 Apr 2000 16:38:38 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200004022338.QAA51565@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
References: <200004021752.KAA13175@freefall.freebsd.org> <20000402163552.P21029@fw.wintelcom.net> <200004022312.QAA51299@apollo.backplane.com> <20000402164700.R21029@fw.wintelcom.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


: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