From owner-freebsd-current Thu Jul 29 20:35:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 9283C15071 for ; Thu, 29 Jul 1999 20:35:18 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id XAA08101; Thu, 29 Jul 1999 23:32:49 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 29 Jul 1999 23:32:49 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Bill Paul Cc: Matthew Dillon , 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) In-Reply-To: <199907300306.XAA17720@skynet.ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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