Subject: Re: kern/29670: "release of unlocked lock" panic with null fs
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Ken Raeburn <raeburn@raeburn.org>
List: netbsd-bugs
Date: 03/15/2005 20:37:02
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.