Re: vnodes and hard links

[Frank Zerangue <frank.zerangue%gmail.com@localhost>]

Thanks for your response. (source release 5.1)

I discovered that even when the vnode is already active, its use count must be 
incremented
and that is indeed what vget does. The man page for vget() is a bit misleading 
here.  Thus
the reason for the code below:

                mutex_enter(&pvnode->v_interlock);
                while (vget(pvnode, LK_EXCLUSIVE | LK_INTERLOCK))  {
                        mutex_enter(&pvnode->v_interlock);
                }

Regards,
Frank

On Apr 20, 2011, at 3:09 AM, David Holland wrote:

> On Tue, Apr 19, 2011 at 01:36:36PM -0500, Frank Zerangue wrote:
>> I am confused about what vnode operation vop_lookup_desc should
>> return for two directory entries that refer to the same underling
>> filesystem inode (i.e. hard links).
>> 
>> // VNODE(9): There is a unique vnode allocated for each active
>> file, directory, mounted-on file, fifo, domain socket, symbolic
>> link and device."
>> 
>> Does this mean that (1) a unique vnode per directory entry or (2) a
>> unique vnode per inode ?
> 
> Per inode.
> 
>> I suspect that the answer is (2), but when I do this and just
>> return the already locked vnode, I get this assertion.
>> 
>> //   Reader / writer lock error: rw_vector_exit: assertion failed: 
>> RW_COUNT(rw) != 0
> 
> Where does this come from? (As in, where's the VOP_UNLOCK it's choking
> on?) Is the nmae you're looking up "." or ".."? Are you working on
> -current or -5 (or -4)?
> 
>> Examples from other filesystems in the code base either do the same
>> or perform a vget() based some flags, but if the vnode is active it
>> would not be on the free list.
> 
> Unfortunately, the locking for lookup is a horrible mess.
> 
> -- 
> David A. Holland
> dholland%netbsd.org@localhost