Date: Fri, 13 Sep 2002 02:45:36 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Terry Lambert <tlambert2@mindspring.com> Cc: Don Lewis <dl-freebsd@catspoiler.org>, current@FreeBSD.ORG, jeff@FreeBSD.ORG Subject: Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself Message-ID: <200209130245.aa42965@salmon.maths.tcd.ie> In-Reply-To: Your message of "Thu, 12 Sep 2002 09:42:37 PDT." <3D80C3FD.EE87B20D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3D80C3FD.EE87B20D@mindspring.com>, Terry Lambert writes: >Ian Dowse wrote: >> And I've just remembered a fifth :-) I think the old BSD code had >> both an `open' count and a reference count. The open count is a >> count of the real users of the vnode (it is what ufs_inactive really >> wants to compare against 0), and the reference count is just for >> places that you don't want the vnode to be recycled or destroyed. >> This was probably lost when the encumbered BSD sources were rewritten. > >No, this went away with the vnode locking changes; it was in the >4.4 code, for sure. I think references are the correct thing here, >and SunOS seems to agree, since that's how they implement, too. 8-). I seem to have mis-remembered the details anyway :-) It doesn't look as if there ever was ever the `open' count that I mentioned above. Maybe I was just thinking that it would be a good way to solve the issues of matching VOP_CLOSEs with VOP_OPENs, since there are many cases in the kernel that do not guarantee to do a VOP_CLOSE for each VOP_OPEN that was performed. Handling the dropping of a last reference is always tricky to get right when complex operations can be performed from the reference dropping function (especially where that includes adding and then removing references multiple times). It's even harder to do it in a way that continues to catch missing or extra references caused by bugs in the functions called when the reference count hits zero. For example, if you hold the reference count at 1 while calling the cleanup function, it allows that function to safely add and drop references, but if that cleanup function has a bug that drops one too many references then you end up recursing instead of detecting it as a negative reference count. I've found in some other code that it works reasonably well to leave the reference count at zero, but set a flag to stop further 1->0 transitions from retriggering the cleanup. Obviously other approaches will work too. Ian 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? <200209130245.aa42965>