The following reply was made to PR kern/29670; it has been noted by GNATS.

From: Ken Raeburn <raeburn@raeburn.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/29670: "release of unlocked lock" panic with null fs
Date: Tue, 15 Mar 2005 15:35:36 -0500

 I went over part of the stack trace data with gdb...
 
 > panic+0x108
 > _lockmgr+0xeb
 kern_lock.c line 566
 > layer_unlock+0x56
 layer_vnops.c line 679
 
 This is the last line of the function -- meaning either of the "return 
 lockmgr(...)" calls could've been executing.
 
 > VOP_UNLOCK+0x28
 vnode_if.c line 1112
 > layer_inactive+0x15
 layer_vnops.c line 758
 > VOP_INACTIVE+0x28
 vnode_if.c line 1025
 > vput+0x11a
 vfs_subr.c line 1322
 > lookup+0x283
 vfs_lookup.c line 664
 
 This is after the "bad" and "bad2" labels, with dpunlocked==0.
 
 I foolishly deleted my old netbsd.gdb when building and installing the 
 new LOCKDEBUG kernel, but I did try to trace through what was going on 
 in this function once before with a crash dump.  I think my writeup was 
 lost in another panic, but as I recall, error was set to ENFILE.  In 
 combination with dpunlocked==0, this can only happen via the "if (error 
 != EJUSTRETURN) goto bad" statement at line 532, which means it was 
 VOP_LOOKUP (presumably in the null file system) that returned ENFILE, 
 and I would guess, with the supplied parent vnode unexpectedly 
 unlocked?
 
 I see that layer_lookup can call LAYERFS_UPPERUNLOCK on the supplied 
 vnode if cnp->cn_flags has PDIRUNLOCK set; should lookup be testing 
 this flag in the "!= EJUSTRETURN" case as it does in the ENOENT case, 
 and set dpunlocked accordingly?  There is one case where layer_lookup 
 can return EROFS without going to the PDIRUNLOCK test, and another 
 where it can set the error to EROFS but still fall through into the 
 test, so it might not be that simple.  But if layer_lookup calls 
 LAYERFS_UPPERUNLOCK and then layer_node_create returns ENFILE, might 
 that trigger this panic?
 
 > namei+0x138
 vfs_lookup.c line 172
 > sys_access+0x75
 > syscall_plain+0x7e
 
 Oh, one more bit of information, which may or may not be relevant.  All 
 the underlying ffs file systems are mounted with the "synchronous" 
 attribute, specifically because of these panic problems.