On Thu Jun 28 2007 at 20:38:40 +0900, YAMAMOTO Takashi wrote:
> > 0x1047d5c is in nfs_inactive (../../../../nfs/nfs_node.c:272).
> > 267                      */
> > 268     
> > 269                     error = vn_lock(sp->s_dvp, LK_EXCLUSIVE | LK_CANRECURSE);
> > 270                     if (error || sp->s_dvp->v_data == NULL) {
> > 271                             /* XXX should recover */
> > 272                             panic("%s: vp=%p error=%d", __func__, sp->s_dvp, error);
> > 273                     }
> > 274                     nfs_removeit(sp);
> > 275                     kauth_cred_free(sp->s_cred);
> > 276                     vput(sp->s_dvp);
> > 
> > What is this test for? Is it to protect vput()? But nfs_unlock() already deals
> > with v_data == 0. Or has this vnode been reclaimed already (how could I tell
> > from ddb?)
> 
> sh vnode 0xd6dd9e0
> 
> if dvp have been revoked (v_data == NULL), nfs_removeit() doesn't work.
> probably it isn't critical enough to panic, but it should be fixed eventually.

And it can happen only in unmount(MNT_FORCE), since otherwise sillyrename
holds a reference.  This might actually be fairly easy to duplicate by
opening a file, removing it and doing unmount -f.

Maybe we should record a dependency to sillyrenamed nodes in the
parent and force flushing of those before flushing the parent node.

I'd tend to not care except that otherwise we leave .nfs-files hanging
around.

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"