On Fri Feb 02 2007 at 08:05:00 +0000, arto@selonen.org wrote:
> At the moment, I don't have any network traces for possible client traffic, but I have a "db> reboot 0x104" crash dump of the latest panic, and the following function call trace (just to give an idea of what is going on):
> 
> panic: lockmgr: release of unlocked lock!
> Stopped in pid 542.1 (nfsd) at netbsd:cpu_Debugger
> db> tr
> cpu_Debugger
> panic
> lockmgr
> nfs_unlock
> VOP_UNLOCK
> ufs_inactive
> VOP_INACTIVE
> vput
> nfsrv_rename
> nfssvc_nfsd
> sys_nfssvc
> syscall_plain

Hey Artsi,

Seems the problem is caused when attempting to rename stuff without
enough permissions.  What's happening under the hood is that nfs_namei()
now releases the lock on the directory vnode in case of an error, so
releasing it again in nfsrv_rename() causes the panic.

The attached patch should fix it.  But I'd like Chuck (cc'd) to review
it before it goes into the tree.

Index: nfs_serv.c
===================================================================
RCS file: /cvsroot/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.122
diff -u -r1.122 nfs_serv.c
--- nfs_serv.c	4 Jan 2007 20:24:08 -0000	1.122
+++ nfs_serv.c	3 Feb 2007 15:14:20 -0000
@@ -1897,8 +1897,6 @@
 		nfsm_reply(2 * NFSX_WCCDATA(v3));
 		nfsm_srvwcc_data(fdirfor_ret, &fdirfor, fdiraft_ret, &fdiraft);
 		nfsm_srvwcc_data(tdirfor_ret, &tdirfor, tdiraft_ret, &tdiraft);
-		if (fdirp)
-			vput(fdirp);
 		vn_finished_write(mp, 0);
 		return (0);
 	}

-- 
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"