From owner-cvs-src@FreeBSD.ORG Mon Sep 12 19:42:54 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org 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 4977F16A420; Mon, 12 Sep 2005 19:42:54 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A36F43D49; Mon, 12 Sep 2005 19:42:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 12 Sep 2005 15:58:29 -0400 From: John Baldwin To: Scott Long Date: Mon, 12 Sep 2005 15:27:15 -0400 User-Agent: KMail/1.8 References: <200509022021.j82KLnZ4076136@repoman.freebsd.org> <4318BCB5.5050001@samsco.org> In-Reply-To: <4318BCB5.5050001@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509121527.17178.jhb@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 12 Sep 2005 19:42:54 -0000 On Friday 02 September 2005 04:57 pm, Scott Long wrote: > John Baldwin wrote: > > jhb 2005-09-02 20:21:49 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern kern_mutex.c > > Log: > > - Add an assertion to panic if one tries to call mtx_trylock() on a > > spin mutex. > > Explaining exactly why this is bad, either in a commit log, in a > manpage, or in source code comments would be really nice. The pitfalls > are not immediately obvious to the casual observer. I can update the manpage. mtx_trylock() has never worked for spin mutexes since its import from BSD/OS. If we ever wanted one (I can think of one useful case in the idle loop perhaps) then it would be called mtx_trylock_spin() anyways. > > - Don't panic if a spin lock is held too long inside _mtx_lock_spin() > > if panicstr is set (meaning that we are already in a panic). Just keep > > spinning forever instead. > > If panicstr is set, shouldn't all CPUs have already been sent an NMI? > This seems like a step backwards in reliability. They should not recursively panic, yes, but in practice they do and once they do you can't get into the debugger. Just ask Kris if this is an improvement. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org