Re: Vnode API change: VOP_LOCK

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Fri, 21 Feb 2014 12:35:40 +0100
   From: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>

   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.