Date: Fri, 21 Feb 2014 12:35:40 +0100 From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de>
Diff available at http://www.netbsd.org/~hannken/vnode-pass3-1.diff Comments or objections anyone? This seems needlessly complicated to me. Outside of the vfs lifecycle code, why would you ever want to lock a dead vnode? It seems to me it would be better to just bite the bullet, kill LK_RETRY, and make everyone handle possible vn_lock failure (or VOP_LOCK, since vn_lock would cease to be necessary). The LK_INTERLOCK flag doesn't seem right. It looks like the only place you use it is a place where you recently removed some code to drop the interlock before taking the vnode lock. We ought to be removing superfluous extra states, not adding more lock order workarounds, especially ones that involve asking more of the particular file systems by passing them new flags. A little more broadly, do you have a plan for what the vnode life cycle should look like? We ought to have a well-defined set of states that a vnode can be in (something like embryonic, active, cached, dead) and a clear set of transitions with invariants and lock order and a clear protocol for file systems to implement. Without that, I'm sceptical of churn in vrelel, vclean, &c.