doing vfs_hash_get when vnode locked

[Kostik Belousov]

On Tue, Aug 05, 2008 at 11:09:00AM -0400, Rick Macklem wrote:
> 
> 
> On Tue, 5 Aug 2008, Kostik Belousov wrote:
> 
> >On Mon, Aug 04, 2008 at 05:04:58PM -0400, Rick Macklem wrote:
> >>There's a place in my nfsv4 client where I need to vfs_hash_get() when
> >>another blocked thread may be holding a lock on the vnode. (It's during
> >>a recovery case where the other threads are blocked, so there isn't a
> >>race problem, as far as I understand it.)
> >>
> >>For FreeBSD7, all I did was call vfs_hash_get() with flags == 0 and it
> >>gave me what I wanted (the vnode for the file handle with a reference
> >>count, but no lock).
> >>
> >>For FreeBSD-CURRENT/8, this no longer works, because vfs_hash_get() calls
> >>vget(), which calls _vn_lock() and _vn_lock() now complains if the lock
> >>type field of "flags" is 0. I came up with a really ugly workaround, by
> >>setting the flags arg. to LK_EXCLOTHER for vfs_hash_get() and then
> >>providing my own VOP_LOCK1() which just VI_UNLOCK()s and returns 0 for
> >>this case (doing the same as vop_stdlock() for other cases). Yuck!!
> >>
> >>Is it possible to re-enable the case of _vn_lock() getting a locktype
> >>field == 0 (or defining one that says "just return 0 unless VI_DOOMED"),
> >>so I don't need the dirty hack?
> >
> >I do not quite understand what you really need there. The non-locked
> >vnode may be reclaimed at any moment, so the check for !VI_DOOMED
> >returns no useful information.
> >
> I need a referenced vnode (v_usecount incremented, which I thought would
> avoid it being recycled) when another blocked thread in the kernel has
No, this is a wrong assumption. Use count does not prevent the vnode
from being reclaimed.

Unless you held the vnode lock, it may be reclaimed. To set the
VI_DOOMED flag, both exclusive vnode lock and vnode interlock must be
held.

> the vnode locked. (This thread is doing recovery while the other blocked
> thread is waiting for that recovery to complete.)
If you can guarantee that the other thread does not relinquish the vnode
lock while curthread operates on the vnode, you may use vref() and
direct check on VI_DOOMED. I shall admit that this is quite perversive
and fragile.

> 
> For FreeBSD7, I call vfs_hash_get(mntp, hash, 0, td, &nvp, mycmpfh, nfhp)
> for this case. It:
> - calls vget() with (0 | LK_INTERLOCK) for flags
>   - it calls vn_lock() with the flags as above
>     - _vn_lock() simply checks for VI_DOOMED and then, otherwise,
>       returns 0 because (flags & LK_TYPE_MASK) == 0
>   - vget then calls v_upgrade_usecount(), incrementing the use count
>    (so it won't be recycled, as I understand it)
> --> and I get the vnode with an incremented usecount that I need. When
>     this thread is done with it, it simply vrele(vp)'s it.
> 
> For FreeBSD-CURRENT, this panics because there is now a check at the
> beginning of _vn_lock() requiring an non-zero LK_TYPE_MASK field.
> (I worked around it by using LK_EXCLOTHER instead of 0 as the argument to
>  vfs_hash_get() and then implemented by own nfs_lock1() VOP, that handles
>  the bogus case of the LK_TYPE_MASK being set to LK_EXCLOTHER by just
>  returning 0 after VI_UNLOCK(vp) if LK_INTERLOCK is set. For all other
>  cases, it calls _lockmgr_args() just like vop_stdlock().)
> 
> Did this help or just muddy the waters? rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080805/fafbc09e/attachment.pgp