Locking rules for symlink vnode op have changed some time ago (rev. 1.26
of coda/coda_vnops.c), perhaps the change triggered some
problem in coda?
I'd probably also check that the lookup() call in coda_symlink()
succeeds, and that nd.ni_vp is indeed NULL in  that case, since
that appears to be what the code assumes.

Jaromir

Greg Troxel wrote:
> I found that the double-vput problem in vfs_lookup was due to a vnode
> with type V_BAD.  This is passed to vfs_lookup from coda_symlink.
> Most of the time, the coda_call to symlink in coda_symlink works, and
> occasionally the call returns without error but the vnode is marked
> VBAD.
> 
> I checked for VBAD, and returned -1, but promptly got a panic in
> nfs_symlink, I think because an mbuf that was free()'d was trashed or
> just a bad pointer.
> 
> So, I'm guessing that the coda kernel code occasionally messes up, or
> there is some locking problem where the vnode gets modified/marked bad
> by something else.  This is all on a 192 MB i386 running
> cfsd/rpcbind/mountd, venus, bash, emacs, sshd/ntpd/etc.  and 3 more
> gettys.  There is basically nothing else going on, and the machine was
> freshly booted.
> 
> I am just beginning to grasp the locking rules, and I'd appreciate
> being set straight if I am confused (and thanks to those who already
> responeded):
> 
>   the interlock in the vnode protects the vnode ref counts and a few
>   other fields in the struct vnode.  It is held for short periods only
>   and is not about locking the vnode itself.
> 
>   Having a reference, expressed via the ref count field, protects you
>   against the vnode going away or turning into something completely
>   different.  But it does not guarantee anything about operations on
>   the vnode; to serialize those, the vn_lock is used.
> 
>   struct lock v_lock in the vnode protects the vnode in the larger
>   context in terms of fs operations.
> 
>   When the comments say 'the locked vnode', they always mean the
>   struct lock in the vnode (or rather v->v_vnlock, which in the coda
>   case always points to v->v_lock since there is no stackable fs stuff
>   going on).
> 
>   Little mention is made of the interlock in terms of locking
>   discussions, other than in vnode(9), because that's too obvious.
> 
>   vput, for example, expects that the interlock is not held.  It
>   unlocks *v->vn_lock, and then decrements usecount.  To do the
>   latter, it has to acquire the interlock, but that's not mentioned.
> 
>   One should in general not hold the interlock when calling VOP_LOCK
>   and VOP_UNLOCK or other vnops.  But some operations take the
>   LK_INTERLOCK flag to indicate that the interlock is already held.
> 
> So, is it reasonable for an unlocked vnode to change to VBAD?
> 
> Does holding the vn_lock mean that vgone should not be called?
> 
> Is there any place else I should suspect that is changing the type to
> VBAD?
> 
>         Greg Troxel <gdt@ir.bbn.com>
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-