From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 15:53:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D25C116A4CF; Sun, 27 Jun 2004 15:53:33 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8655743D2F; Sun, 27 Jun 2004 15:53:33 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5RFrLRx074680; Sun, 27 Jun 2004 11:53:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5RFrLad074677; Sun, 27 Jun 2004 11:53:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 27 Jun 2004 11:53:21 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Tim Robbins In-Reply-To: <20040627133421.GA15812@cat.robbins.dropbear.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Pawel Jakub Dawidek Subject: Re: Confusion about process states and invariants X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2004 15:53:34 -0000 On Sun, 27 Jun 2004, Tim Robbins wrote: > > Couldn't we move crhold() for p_ucred before it is placed on allproc > > list? > > p_ucred is just the tip of the iceberg -- a lot of code assumes that > processes on allproc are fully set up. We should either delay putting > the process onto allproc until it's correctly initialized (taking care > to avoid races in PID allocation), or not drop the allproc sx until > initialization is done. Yeah, it seems there are only two reasonable strategies: (1) Guard all accesses to proc references to make sure they are aware of the process state machine and when they can expect certain fields to be valid or usable. This might include causing pfind() not to return improper processes. (2) Don't expose processes in "poor" states to the various consumers of processes, allowing the invariants expected by those consumers to be stronger. Some magic would be required here in ways you and I have discussed previously, such as managing to avoid collisions on pids, etc. I prefer (2) since it avoids putting "Hmm, is it real" logic all over the kernel, but am unwilling to make the change without a proper understanding of what should be going on. I also don't have time to make the change immediately, so was trolling for someone willing to work on it :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research