From owner-freebsd-current Tue Jan 11 0:34:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from 1Cust15.tnt1.washington.dc.da.uu.net (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 290AF151F4; Tue, 11 Jan 2000 00:34:46 -0800 (PST) (envelope-from green@FreeBSD.org) Date: Tue, 11 Jan 2000 03:34:43 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Stephen McKay Cc: freebsd-current@freebsd.org Subject: Re: Crash from ^T during heavy paging In-Reply-To: <200001100735.RAA51943@nymph.detir.qld.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 10 Jan 2000, Stephen McKay wrote: > The problem is that calcru() thinks that P_INMEM means that the proc > structure is fully and accurately populated. But P_INMEM is one of the > first flags set. > > So, calcru() and possibly some other places, are looking at a struct proc > before it's all there. What's the "proper" way to do it? It should really be one of the _last_ flags set, if it's to mean anything. I don't know how to explain the prevalance of race conditions in the old code, except to say it probably has to do with not planning ahead. Certainly it's not acceptable to create new race conditions now (even if it can happen by accident). So, here's something to defer P_INMEM til the end, when the process is really "ready": --- sys/kern/kern_fork.c Tue Dec 7 22:11:35 1999 +++ /tmp/kern_fork.c Tue Jan 11 03:32:44 2000 @@ -351,7 +351,7 @@ * Increase reference counts on shared objects. * The p_stats and p_sigacts substructs are set in vm_fork. */ - p2->p_flag = P_INMEM; + p2->p_flag = 0; if (p1->p_flag & P_PROFIL) startprofclock(p2); MALLOC(p2->p_cred, struct pcred *, sizeof(struct pcred), @@ -499,6 +499,7 @@ microtime(&(p2->p_stats->p_start)); p2->p_acflag = AFORK; (void) splhigh(); + p2->p_flag |= P_INMEM; p2->p_stat = SRUN; setrunqueue(p2); (void) spl0(); -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message