Date: Mon, 12 Sep 2005 15:27:15 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Scott Long <scottl@samsco.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c Message-ID: <200509121527.17178.jhb@FreeBSD.org> In-Reply-To: <4318BCB5.5050001@samsco.org> References: <200509022021.j82KLnZ4076136@repoman.freebsd.org> <4318BCB5.5050001@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509121527.17178.jhb>