Date: Wed, 13 Nov 1996 10:32:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: michaelh@cet.co.jp, ponds!rivers@dg-rtp.dg.com, Hackers@FreeBSD.org Subject: Re: Even more info on daily panics... Message-ID: <199611131732.KAA22431@phaeton.artisoft.com> In-Reply-To: <199611130504.VAA07192@root.com> from "David Greenman" at Nov 12, 96 09:04:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I would also like to hear an explaination of how it is possible, after the > patch to vrele to prevent it from going negative, for a vnode with a non-zero > v_usecount can be on the freelist in the first place. Please check my previous mail... There is a race condition caused by the fact that the vnode reclamation is "smeared" across the VFS/FS boundry layer. It is not obvious unless you consider interfaces to represent access points for automatons instead of simply functional abstractions of object complexity (ie: it is an artifact of layering errors). Another way of stating this is to think of execution contexts as moving from place to place, rather than sleeping and waking up. It's very important to view things like this in any case for SMP, where a context should be considered as an anonymous, schedulable resource to apply to outstanding work-to-do. The only difference here is that there is only one schedulable resource, and we currently do not have to worry about reentrancy. The problem with a "smeared" task is that you can "reenter" without crossing the interface boundry... so protecting against recossing the boundry does not necessarily protect against the race condition. This really needs a whiteboard; I explain better with pictures, and "ascii art" just won't cut it for drawing a cyclic graph. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611131732.KAA22431>