Date: Tue, 25 Jul 2000 11:35:37 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: Ollivier Robert <roberto@eurocontrol.fr>, freebsd-current@FreeBSD.org, Stephan van Beerschoten <stephanb@whacky.net>, Robert Watson <rwatson@FreeBSD.org> Subject: Re: Panic: bqrelse: multiple refs Message-ID: <200007251835.LAA13336@beastie.mckusick.com> In-Reply-To: Your message of "Tue, 25 Jul 2000 11:47:03 EDT." <Pine.BSF.4.21.0007251128550.752-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Tue, 25 Jul 2000 11:47:03 -0400 (EDT) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Ollivier Robert <roberto@eurocontrol.fr> Cc: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>, mckusick@mckusick.com Subject: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking In-Reply-To: <20000725170455.F636@caerdonn.eurocontrol.fr> On Tue, 25 Jul 2000, Ollivier Robert wrote: > According to Brian Fundakowski Feldman: > > Actually, I'm pretty certain this is the fix: > > Well it won't panic but isn't it putting the problem under the carpet? > I agree the panic seems to be here temporarely but... No, I'm really certain this isn't the case. You see, struct buf has a b_lock that until recently was a plain, exclusive lockmgr lock. In Kirk's last round of changes, he converted b_lock to be LK_CANRECURSE, which means that the lock, while still an exclusive lock, may be relocked multiple times by the same caller. The panics are plain wrong. What's left is to determine what is the proper thing to do in each of these cases, which I'm certain that many people already know already (you see, I'm still a bit green ;). What I am _almost_ sure about is that the right thing is just to remove one of the locks and let it get freed back up the call chain. I'm almost certain this is the case because if you are grabbing exclusive locks and recursing upon them, your call chain is the only consumer and in a recursive-locking-callchain, you will have multiple symmetric lock and unlock pairs. Anything else horribly complicates things, and this makes me a good 95% certain that this is exactly the right fix, not that it's sweeping any true bugs under the carpet. Allowing recursive locks is pretty much the only way to solve many of the problems here because it's simply not possible to support all code paths without allowing for this recursion. The code would either be horribly complicated or non-functional. I'm certain Kirk may be able to back me up here. It seems that the cleanup is meant to make the locks recursive mostly to facilitate correct/proper call chains, and that's consistent with my understand at least :) Indeed, if you look at the comment in brelse() from the delta, you will see that the intention of allowing this very situation to occur and simply BUF_UNLOCK() was planned for and the panic()s were for debugging during the previous time that b_locks weren't LK_CANRECURSE. As always, take what I say with a grain of salt since I'm definitely not a VFS guru in any manner; I just happen to think I understand this one :) > -- > Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr > The Postman hits! The Postman hits! You have new mail. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' The above explanation is correct. When I made the change to allow recursive buffer locks, I should have removed that panic (but forgot that I had put it in there, sigh). I have just made the change on freefall. Sorry for the problems caused by that change. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007251835.LAA13336>