CVS commit: src/sys/nfs

[Bill Studenmund <wrstuden%netbsd.org@localhost>]

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.