NetBSD Problem Report #49491

From mrg@eterna.com.au  Sun Dec 21 06:25:23 2014
Return-Path: <mrg@eterna.com.au>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CC6CDA5809
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 21 Dec 2014 06:25:23 +0000 (UTC)
Message-Id: <20141221062519.5236FB37E@splode.eterna.com.au>
Date: Sun, 21 Dec 2014 17:25:19 +1100 (EST)
From: mrg@eterna.com.au
Reply-To: mrg@eterna.com.au
To: gnats-bugs@gnats.NetBSD.org
Subject: umidi record locking problem
X-Send-Pr-Version: 3.95

>Number:         49491
>Category:       kern
>Synopsis:       umidi record locking problem
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 21 06:30:00 +0000 2014
>Closed-Date:    Thu Aug 17 18:50:02 +0000 2017
>Last-Modified:  Thu Aug 17 18:50:02 +0000 2017
>Originator:     matthew green
>Release:        NetBSD 7.99.3
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
System: NetBSD phat-bass 7.99.3 NetBSD 7.99.3 (_phat_) #5: Fri Dec 19 17:51:35 PST 2014  mrg@xotica:/var/obj/i386/usr/src7/sys/arch/i386/compile/_phat_ i386
Architecture: i386
Machine: i386
>Description:

	this simple command, with LOCKDEBUG, asserts:

		% cat /dev/rmidi2 > /tmp/f

	with this stack trace:

	panic: LOCKDEBUG: Mutex error: lockdebug_barrier: spin lock held
	cpu0: Begin traceback...
	vpanic(c08de553,db768bfc,db768c1c,c05f4b78,c08de553,c08afd84,c085770c,c08de606,1,c085770c) at netbsd:vpanic+0x11a
	snprintf(c08de553,c08afd84,c085770c,c08de606,1,c085770c,c3471cc0,c33c2260,c33c2260,db768c7c) at netbsd:snprintf
	lockdebug_more(c08de606,1,0,0,c2f7f100,c0a7c4c0,c05f4936,c0a7c4c0,0,c35cad40) at netbsd:lockdebug_more
	mutex_enter(c33c2260,c3471cc0,5,c3ce9e8c,db768cbc,c06c4073,c3471cc0,0,c3c146cc,c0487646) at netbsd:mutex_enter+0x48e
	uhci_device_bulk_transfer(c3471cc0,0,c3c146cc,c0487646,c3471d08,c31da880,0,c354ed40,db768ce8,c06b6066) at netbsd:uhci_device_bulk_transfer+0x23
	usbd_transfer(c3471cc0,c3ce9e8c,c31da880,db684c80,8,5,0,c06b6215,c35b2cd0,db768d1c) at netbsd:usbd_transfer+0x4a
	start_input_transfer(c344b284,c040c4cb,8,c05ebda0,c344b286,3a01,db768db4,c31da880,c3af1008,0) at netbsd:start_input_transfer+0x50
	umidi_open(c35b2cd0,1,c04890ea,c048804c,c3af1008,3a01,3a01,db768db4,db768da0,c05d342f) at netbsd:umidi_open+0x1c3
	midiopen(3a01,0,1,2000,c35cad40,0,c397bf30,c3981378,3a,c067fa5d) at netbsd:midiopen+0x179
	spec_open(db768db4,db768ea4,db768ecc,c086e694,c3981378,1,c3cb8a80,1,db768e80,c071109a) at netbsd:spec_open+0x1f3
	VOP_OPEN(c3981378,1,c3cb8a80,8,c03f5c8c,c3981378,c3981378,ffffffff,db768dfc,c07498b1) at netbsd:VOP_OPEN+0x32
	vn_open(db768ea4,1,0,c0a7c684,c3487e80,c3c978c0,3,0,c3cbd3a0,c3caec00) at netbsd:vn_open+0x1fe
	do_open(c35cad40,0,c3cbd3a0,0,0,db768f38,0,c3cbd3a0,c35cad40,db768fa8) at netbsd:do_open+0xc0
	do_sys_openat(0,0,db768f38,c0a2b75c,db768f9c,c061dd26,c35cad40,db768f68,db768f60,1) at netbsd:do_sys_openat+0x6f
	sys_open(c35cad40,db768f68,db768f60,1,c352bb98,5,db768f68,0,0,bfbffc48) at netbsd:sys_open+0x2c
	syscall() at netbsd:syscall+0x86

>How-To-Repeat:

	see above.

>Fix:

>Release-Note:

>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: kern/49491: umidi record locking problem
Date: Sun, 21 Dec 2014 19:22:46 +1100

 ah, the problem here is that the umidi lock, which is taken by
 midiopen(), is a spin lock, but the usb lock attempted to be
 taken later is an sleeping lock, and that's not allowed.

 i have not yet looked at if we can change umidi's lock.


 .mrg.

State-Changed-From-To: open->pending-pullups
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Tue, 23 Dec 2014 11:35:14 +0000
State-Changed-Why:
i've fixed the umidi specific problems in current.


State-Changed-From-To: pending-pullups->closed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Thu, 17 Aug 2017 18:50:02 +0000
State-Changed-Why:
This was fixed in rev. 1.66 of umidi.c, which is not on netbsd-7, but is partt
of netbsd-8. Closing for now, ping if you think this is safe to be pulled
to netbsd-7.


>Unformatted:

Home	PR Database Search