Date: Wed, 8 Apr 2009 20:38:44 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Ed Schouten <ed@80386.nl> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Ivan Voras <ivoras@freebsd.org> Subject: Re: kbdmux vs ATA? (was: ATA related panic during ZFS scrub) Message-ID: <alpine.BSF.2.00.0904082035190.33212@fledge.watson.org> In-Reply-To: <20090408193319.GK32098@hoeg.nl> References: <20090408170231.K38445@rust.salford.ac.uk> <grit3p$oem$1@ger.gmane.org> <20090408193319.GK32098@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Apr 2009, Ed Schouten wrote: > * Ivan Voras <ivoras@freebsd.org> wrote: >> Hmmm, this shows a lock order problem between ATA and kbdmux's Giant. > > The current state of the input layer is a mess. I guess the policy was to > not pick up any locks while in the debugger. Picking up Giant there is one > of the most awful things that can happen, right? As a general rule, the low-level console interfaces should acquire at most spinlocks in normal operation (cngetc, cnputc, etc), and no locks at all when in the debugger (kdb_active). The reason for the second rule should be obvious, but the reason for the first rule is less obvious: it's called during the boot in all kinds of sensitive places as a result of calls to printf(9), so has to be willing to run under the most sticky of circumstances. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904082035190.33212>