Subject: CVS commit: src/sys/nfs
To: None <source-changes@NetBSD.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: source-changes
Date: 01/23/2004 22:20:21
Module Name:	src
Committed By:	wrstuden
Date:		Fri Jan 23 22:20:21 UTC 2004

Modified Files:
	src/sys/nfs: nfs_node.c

Log Message:
Adjust sillyrename cleanup code to deal with the parent vnode
already being locked by our thread. VOP_INACTIVATE() makes no
statement as to the lock state of the parent, yet this code assumed
we had it unlocked.

With this change, we let vn_lock() fail with EDEADLK if we already
have the parent locked. We then handle the rename cleanup, and on
the way out just vrele() the parent vnode, not vput() it.

Fixes a case seen by Steve Woodford at Wasabisystems dot com where
we'd panic while running a pkgsrc configure test that verified
fork() functionality. I expect the problem is a result of the recent
exit() changes and the performance of the machines he tested on.

Specifically we would crash during an nfs_remove(). As best I can
tell, when nfs_remove() tested to see if we should rename or we
should remove, v_usecount was > 1 and vattr.va_nlink was 1. Thus
we did the sillyrename in nfs_remove(). However by the time we got
down to the vput(vp), v_usecount had dropped to one and thus vput()
triggered the VOP_INACTIVATE() code path. nfs_inactive() tries to
lock the parent to undo the sillyrename, and deadlocks as we still
have it locked.


To generate a diff of this commit:
cvs rdiff -r1.71 -r1.72 src/sys/nfs/nfs_node.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.