From owner-cvs-src@FreeBSD.ORG Mon May 12 23:47:25 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E59BC37B401; Mon, 12 May 2003 23:47:25 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A1D743FB1; Mon, 12 May 2003 23:47:23 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id QAA24483; Tue, 13 May 2003 16:47:19 +1000 Date: Tue, 13 May 2003 16:47:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: <200305121437.h4CEbl2a098662@repoman.freebsd.org> Message-ID: <20030513161518.W82184@gamplex.bde.org> References: <200305121437.h4CEbl2a098662@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 06:47:26 -0000 On Mon, 12 May 2003, Robert Watson wrote: > rwatson 2003/05/12 07:37:47 PDT > > FreeBSD src repository > > Modified files: > sys/kern vfs_subr.c > Log: > Remove bogus locking from DDB's "show lockedvnods" command: using > synchronization primitives from inside DDB is generally a bad idea, > and in this case it frequently results in panics due to DDB commands > being executed from the sio fast interrupt context on a serial > console. Replace the locking with a note that a lack of locking > means that DDB may get see inconsistent views of the mount and vnode > lists, which could also result in a panic. More frequently, > though, this avoids a panic than causes it. ddb may see inconsistent views, but this is not due to its lack of locking. ddb locks everything, so it sees precisely the current view of everything. It is fundamental that this view might not be consistent, since ddb can't obey normal locking semantics. Using ddb commands fast interrupt context just increases the chance of freezing the system in an inconsistent state. Stopping at ordinary breakpoints gives the same problem if the breakpoints are in critical code. Stopping at a breakpoint in code that is changing the state to be consistent ensures seeing an inconsistent state. Inconsistencies seen by ddb commands shouldn't result in panics unless there are bugs in the commands. ddb commands should do little more than read memory and print the result using db_printf(). If they follow a garbage pointer, then the fault for this is handled and control is returned to ddb using longjmp(). (The fault is actually slightly mishandled by complaining about it in trap() using printf() before giving ddb a chance to catch it.) Calling locking functions from this command was one of the bugs in it. Remaining bugs include: - the command begins with a printf(). ddb commands must use db_printf(). - VOP_ISLOCKED() is called, so the command inherits any bugs from this function not being ddb-aware. Perhaps there are none, but this is hard to see. - vprintf() is called, so the command inherits all bugs from this function not being ddb-aware. vprint() begins with a printf()... Bruce