> On 2. Apr 2017, at 16:05, Taylor R Campbell > <campbell+netbsd-tech-k...@mumble.net> wrote: > >> 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.
Looks like your proposal needs some clarification regarding "vnode lock" and "the lock". We have two vnode related locks: - the "vnode lock", located as field "vi_lock" in "struct vnode_impl" used by genfs_*lock() aka VOP_*LOCK. - the "genfs lock" located as field "g_lock" in "struct genfs_node" used by genfs_node_*lock(). Which lock do you want to be held across VOP_INACTIVE and destroyed from VOP_RECLAIM? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
