Subject: kern/5113: kernel panic when vnconfig'ing
To: None <gnats-bugs@gnats.netbsd.org>
From: None <bouyer@antioche.lip6.fr>
List: netbsd-bugs
Date: 03/03/1998 22:54:54
>Number: 5113
>Category: kern
>Synopsis: kernel panic when vnconfig'ing
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people (Kernel Bug People)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Mar 4 07:05:04 1998
>Last-Modified:
>Originator: Manuel Bouyer
>Organization:
Laboartoire d'Informatique de Paris VI
>Release: NetBSD-current cvs update'ed Mon, 3 march
>Environment:
System: NetBSD rochebonne.lip6.fr 1.3E NetBSD 1.3E (ROCHEBONNE) #5: Tue Mar 3 22:14:03 MET 1998 bouyer@rochebonne.lip6.fr:/home/bouyer/1.3E/src/sys/arch/i386/compile/ROCHEBONNE i386
>Description:
When attaching a file to a vnd device, the kernel panic with
"panic: lockmgr: unknown locktype request 0"
The backtrace looks like:
lockmgr()
ufs_look()
vn_look()
vndstrategy()
readdisklabel()
...
>How-To-Repeat:
vnconfig -v /dev/vnd0d /tmp/ffsfile
>Fix:
The problem is that vndstrategy calls vn_lock() with the second argument
(flags) set to 0. This is passed up to lockmgr().
Passing (LK_EXCLUSIVE | LK_RETRY) solves the problem, but may be a too
conservative approach. The XXX comments here also stats:
"check if vnode is already locked, to avoid
recursive locking. The real solution is to
allow recursive locks here, but the interface
doesn't allow it."
It seems that the lite-2 interface allows recursive locks, but I didn't
go deeper into this.
--- vnd.c.old Tue Mar 3 21:47:54 1998
+++ vnd.c Tue Mar 3 21:51:50 1998
@@ -401,7 +401,7 @@
*/
if (!VOP_ISLOCKED(vnd->sc_vp)) {
dolock = 1;
- vn_lock(vnd->sc_vp, 0);
+ vn_lock(vnd->sc_vp, LK_EXCLUSIVE | LK_RETRY);
}
error = VOP_BMAP(vnd->sc_vp, bn / bsize, &vp, &nbn, &nra);
if (dolock)
>Audit-Trail:
>Unformatted: