Re: locking from VOP_INACTIVE to VOP_RECLAIM

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

> On 2. Apr 2017, at 16:05, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
>> 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.

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 - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)