From owner-freebsd-current Mon Apr 3 17:39:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id 201DE37B74A for ; Mon, 3 Apr 2000 17:39:29 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA53513; Tue, 4 Apr 2000 10:09:11 +0930 (CST) Date: Tue, 4 Apr 2000 10:09:11 +0930 From: Greg Lehey To: Alfred Perlstein Cc: Matthew Dillon , 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: <20000404100911.C53037@freebie.lemis.com> References: <200004021752.KAA13175@freefall.freebsd.org> <20000402163552.P21029@fw.wintelcom.net> <200004022312.QAA51299@apollo.backplane.com> <20000402164700.R21029@fw.wintelcom.net> <200004022338.QAA51565@apollo.backplane.com> <20000402172349.T21029@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000402172349.T21029@fw.wintelcom.net> WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 2 April 2000 at 17:23:49 -0700, Alfred Perlstein wrote: > * Matthew Dillon [000402 17:04] wrote: >> >> :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. > > Good call. > > Ugh, I should think about this more, but i'll just grasp at straws > and suggest that p_pptr is set to volatile variable, and we re-read > it after we snarf the pid from the pointer and make sure it hasn't > changed out from under us. > > Either that or store it in the child's proc struct as well. This seems the obvious solution. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message