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