> Date: Sun, 2 Apr 2017 10:47:42 +0200 > From: "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de> > > > On 1. Apr 2017, at 20:41, Taylor R Campbell > > <campbell+netbsd-tech-k...@mumble.net> 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.
