Re: locking from VOP_INACTIVE to VOP_RECLAIM

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

> Date: Sun, 2 Apr 2017 10:47:42 +0200
> From: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>
> 
> > On 1. Apr 2017, at 20:41, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> > VOP_RECLAIM then *destroys* the lock, so we don't have to say whether
> > it is held or released on exit.  This requires a one-line change to
> > vfs_vnode.c, and then mechanically moving VOP_UNLOCK from *_inactive
> > to *_reclaim throughout the file systems.
> 
> Changing VOP_RECLAIM to destroy the lock forces a complete
> rewrite of the vnode lock mechanism.

Huh?  That part is not a change -- VOP_RECLAIM already destroys the
lock.  E.g., ffs_reclaim calls genfs_node_destroy.

I just added that sentence (`VOP_RECLAIM then destroys the lock...')
to emphasize that my proposed change doesn't need to address the state
of the lock after VOP_RECLAIM returns.

Note that the only call to VOP_RECLAIM in the system immediately
follows VOP_INACTIVE, in vcache_reclaim, so that call actually
requires no changes.  Only the other call to VOP_INACTIVE, in vrelel,
requires a change, to add a following VOP_UNLOCK.