Date: Thu, 29 Jul 1999 23:32:49 -0400 (EDT) From: "Brian F. Feldman" <green@FreeBSD.org> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: Matthew Dillon <dillon@apollo.backplane.com>, peter@netplex.com.au, crossd@cs.rpi.edu, current@FreeBSD.org Subject: Re: readdirplus client side fix (was Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm) Message-ID: <Pine.BSF.4.10.9907292328190.8024-100000@janus.syracuse.net> In-Reply-To: <199907300306.XAA17720@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 Jul 1999, Bill Paul wrote:
> > Ok, I was able to reproduce the above bug and fix it. The problem on
> > the FreeBSD client is in nfs_readdirplusrpc() in nfs/nfs_vnops.c. It
> > can obtain the vnode being used to populate the additional directory
> > info in one of two ways. When it gets the vnode via nfs_nget(), the
> > returned vnode is locked. When it gets it via a hit against NFS_CMPFH()
> > (which I presume is for '.'), it simply VREF()'s the vnode.
> >
> > In the one case the vnode is returned locked, in the other it is not.
> >
> > However, the internal loop vrele()'s the vnode rather then vput()'s it,
> > so the vnodes in the directory scan are never unlocked. This leads to
> > the lockup.
>
> Uh, yeah.
>
> One of these days I'll be able to understand everything that you just
> said. But not today.
It's not hard. vput() VOP_UNLOCK()s a vnode and then vrele() (opposite of
vref())'s it (decreases v_usecount, I believe.) So when a file system
is mounted, with these bugs, the locked vnodes are never unlocked.
The unmount call will end up sleeping with the state "vnlock" waiting for
the operation that has the vnode in question vref()d to vrele() and
let go of it.
At least, that's how it looks to me, but I never really looked at vnode
code until today.
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9907292328190.8024-100000>