From owner-freebsd-current Sun Jun 27 2:49: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 81B1B151B2 for ; Sun, 27 Jun 1999 02:48:57 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA24502; Sun, 27 Jun 1999 10:51:29 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 27 Jun 1999 10:51:29 +0100 (BST) From: Doug Rabson To: Peter Wemm Cc: Matthew Dillon , current@freebsd.org, mckusick@mckusick.com Subject: Re: BUF_LOCK() related panic.. In-Reply-To: <19990627092250.BDE6181@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 27 Jun 1999, Peter Wemm wrote: > Matthew Dillon wrote: > > Ah, yes, some of us were just discussing this in a small mailing list. > > Hopefully Kirk will pick up on it soon. Ah well.. someone else gets to b > e > > the brunt of it for a change :-). Kirk doesn't have an SMP box so he > > didn't see the bug. > > > > I have tentitively tracked the problem down to the apparent inability of > > lockmgr() locks to function from interrupts, even when used in a > > non-blocking manner, due to the simplelock's it uses internally. The > > new buffer cache code Kirk committed switched from B_BUSY (manually > > implemented locks) to lockmgr() locks. I think what is going on is > > that mainline code is getting a simplelock and then an interrupt is > > coming along and also trying to get the same lock, but I can't be sure > > because my DDB backtraces are somewhat munged. > > In this case, it was just a programming error.. The key to remember is that > the simplelocks are used to protect the state of the complex lock, they are > not the lock themselves. lockmgr() holds the interlock while gaining or > removing references etc and then frees the simplelock so that it can sleep > if required etc. The actual implementation of the simplelock routines > is interrupt safe (and has to be). The simple_lock* macros don't seem to use the interrupt safe versions (ss_lock etc). What happens if an interrupt is recieved after gaining buftimelock and the interrupt routine also tries to call BUF_LOCK? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message