Date: Thu, 07 Nov 1996 05:40:59 -0800 From: David Greenman <dg@root.com> To: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> Cc: freebsd-hackers@freebsd.org Subject: Re: More info on the daily panics... Message-ID: <199611071340.FAA03376@root.com> In-Reply-To: Your message of "Thu, 07 Nov 1996 07:54:29 EST." <199611071254.HAA02561@lakes.water.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Also, if v_usecount went negative - wouldn't that only loose >one, or a few vnodes (assuming it went to -1), as v_usecount >was incremented, wouldn't it return to being positive? Also, >since -1 != 0, would that vnode ever be available to be used again? >I'm just thinking out loud... v_usecount is a mechanism for reference counting in-use vnodes. When it drops to 0, it is considered "currently unused" and is placed on the freelist. It's not _completely_ free, however, as there are still references to it from the namecache. If there is a namecache hit, the vnode can be removed from the freelist and used...so vnodes on the freelist form a second chance cache for vnodes. In order for a vnode to be considered not-stale, a match must also occur with the vnode's generation count which is called v_id (which is stored in the namecache along with the pointer to the vnode). If the generation count comparison fails, then the vnode is considered not in the cache and a completely new one is allocated. A vnode is removed from the freelist whenever a reference is gained to it. There is only one case algorithmically that a vnode can be on the freelist and have a non-zero usecount. This is the case where the usecount was once zero (and thus was inserted onto the freelist), and was then later decremented again - causing it to become negative. Later, when a vnode needs to be reclaimed from the freelist, the system does a consistency check on the vnode and if the usecount is not zero, it panics with "free vnode isn't". One potential hack-fix would be, in vrele(), to decrement the v_usecount only if v_usecount != 0. This would prevent it from ever becoming negative and thus duplicate vrele()s would be eaten. The problem with this is that it covers up a potentially serious problem. One can't determine if the extra vrele() may lose a reference that it shouldn't be losing and thus prematurely insert an in-use vnode onto the freelist. Most of the time this probably won't cause your system to die a horrible death, but it could. ...which is why we have consistency checks in the first place. :-) -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611071340.FAA03376>