NetBSD Problem Report #45909

From tih@hamartun.priv.no  Wed Feb  1 15:09:00 2012
Return-Path: <tih@hamartun.priv.no>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 7792663C41D
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  1 Feb 2012 15:09:00 +0000 (UTC)
Message-Id: <20120201143043.98ADA1C932@athene.hamartun.priv.no>
Date: Wed,  1 Feb 2012 15:30:43 +0100 (CET)
From: tih@hamartun.priv.no
Reply-To: tih@hamartun.priv.no
To: gnats-bugs@gnats.NetBSD.org
Subject: Use of MIDI over USB interfaces crashes NetBSD
X-Send-Pr-Version: 3.95

>Number:         45909
>Category:       kern
>Synopsis:       Use of MIDI over USB interfaces crashes NetBSD
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    mrg
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 01 15:10:00 +0000 2012
>Closed-Date:    Tue Mar 06 16:55:08 +0000 2012
>Last-Modified:  Tue Mar 06 17:05:02 +0000 2012
>Originator:     Tom Ivar Helbekkmo
>Release:        NetBSD 5.99.60 as per 2012-01-24
>Organization:
>Environment:
System: NetBSD athene.hamartun.priv.no 5.99.60 NetBSD 5.99.60 (ATHENE) #31: Tue Jan 31 21:40:41 CET 2012 tih@athene.hamartun.priv.no:/usr/obj/sys/arch/i386/compile.i386/ATHENE i386
Architecture: i386
Machine: i386
>Description:

There are problems with locking in the current version of
/sys/dev/usb/umidi.c, causing NetBSD to crash if an attempt is made to
read from a USB MIDI device.  The reason turns out to be that
assumptions about the kernel lock being taken before certain
operations, and about the taking and releasing of mutex spin locks,
are not being correctly upheld by umidi.c.

Specifically, there are four problems:

1: the kernel lock needs to be held while an input transfer is
   initiated (the KASSERT(KERNEL_LOCKED_P()) is found in the function
   usbd_transfer() in /sys/dev/usb/usbdi.c).  I added code to grab and
   release the kernel lock to open_in_jack() in /sys/dev/usb/umidi.c,
   around the call to start_input_transfer().

2: the kernel lock must, again, be held while a transfer is aborted
   (by calling usbd_abort_xfer()).  This happens while closing a MIDI
   interface that was open for reading, and midiclose(), in
   /sys/dev/midi.c, does not itself grab the lock.  Again, a KASSERT()
   fails for this situation.  I added code to grab and release the
   kernel lock to close_in_jack() in /sys/dev/usb/umidi.c.

3: The softc spinlock mutex must *not* be held during the above
   mentioned call to usbd_abort_xfer(), but midiclose() does hold it
   while calling the umidi driver's closing function.  This fails
   because usbd_abort_xfer() wants to relinquish the CPU to allow the
   hardware time to catch up, and a context switch is then attempted
   with the mutex held.  I added code to release and re-grab the mutex
   around the call to usbd_abort_xfer() in /sys/dev/usb/umidi.c.

4: After a MIDI device that was open for read has been closed (with
   the above fixes in place), reopening it for read fails because of
   the state it is left in by usbd_abort_xfer().  Specifically, the
   first attempt to start an input transfer on it returns
   USBD_CANCELLED, reflecting the aborted transfer.  This is benign,
   and I simply added that return code to the set of those that are
   accepted as non-errors by the umidi driver.

>How-To-Repeat:

Attempt to use a USB MIDI interface on -current, reading and writing
it both directly (/dev/rmidi?) and through the sequencer (/dev/music).
Observe that writing works, but reading crashes NetBSD.

>Fix:

Apply the following patch (thoroughly tested with two Roland UM-ONE):

Index: umidi.c
===================================================================
RCS file: /cvsroot/src/sys/dev/usb/umidi.c,v
retrieving revision 1.55
diff -u -r1.55 umidi.c
--- umidi.c	23 Dec 2011 00:51:47 -0000	1.55
+++ umidi.c	1 Feb 2012 13:31:11 -0000
@@ -64,7 +64,7 @@
 #define DPRINTFN(n,x)	if (umididebug >= (n)) printf x
 #include <sys/time.h>
 static struct timeval umidi_tv;
-int	umididebug = 0;
+int	umididebug = 1;
 #else
 #define DPRINTF(x)
 #define DPRINTFN(n,x)
@@ -255,6 +255,7 @@
 error:
 	aprint_error_dev(self, "disabled.\n");
 	sc->sc_dying = 1;
+	KERNEL_UNLOCK_ONE(curlwp);
 	return;
 }

@@ -349,7 +350,8 @@
 	if ((mididev->flags & FREAD) && mididev->in_jack) {
 		err = open_in_jack(mididev->in_jack, arg, iintr);
 		if ( err != USBD_NORMAL_COMPLETION
-		&&   err != USBD_IN_PROGRESS )
+		&&   err != USBD_IN_PROGRESS
+		&&   err != USBD_CANCELLED )
 			goto bad;
 	}

@@ -1125,11 +1127,14 @@
 	jack->u.in.intr = intr;
 	jack->opened = 1;
 	if (ep->num_open++ == 0 && UE_GET_DIR(ep->addr)==UE_DIR_IN) {
+		KERNEL_LOCK(1, curlwp);
 		err = start_input_transfer(ep);
 		if (err != USBD_NORMAL_COMPLETION &&
-		    err != USBD_IN_PROGRESS) {
+		    err != USBD_IN_PROGRESS &&
+		    err != USBD_CANCELLED) {
 			ep->num_open--;
 		}
+		KERNEL_UNLOCK_ONE(curlwp);
 	}

 	return err;
@@ -1165,10 +1170,20 @@
 static void
 close_in_jack(struct umidi_jack *jack)
 {
+	struct umidi_endpoint *ep;
+	struct umidi_softc *sc;
+
 	if (jack->opened) {
+		ep = jack->endpoint;
+		sc = ep->sc;
+		KASSERT(mutex_owned(&sc->sc_lock));
 		jack->opened = 0;
 		if (--jack->endpoint->num_open == 0) {
-		    usbd_abort_pipe(jack->endpoint->pipe);
+			KERNEL_LOCK(1, curlwp);
+			mutex_exit(&sc->sc_lock);
+			usbd_abort_pipe(ep->pipe);
+			mutex_enter(&sc->sc_lock);
+			KERNEL_UNLOCK_ONE(curlwp);
 		}
 	}
 }
@@ -1415,12 +1430,17 @@
 static usbd_status
 start_input_transfer(struct umidi_endpoint *ep)
 {
+	usbd_status rv;
+
+	DPRINTFN(200,("umidi in transfer: start %p length %u\n",
+	    ep->buffer, ep->buffer_size));
 	usbd_setup_xfer(ep->xfer, ep->pipe,
 			(usbd_private_handle)ep,
 			ep->buffer, ep->buffer_size,
 			USBD_SHORT_XFER_OK | USBD_NO_COPY,
                         USBD_NO_TIMEOUT, in_intr);
-	return usbd_transfer(ep->xfer);
+	rv = usbd_transfer(ep->xfer);
+	return rv;
 }

 static usbd_status

>Release-Note:

>Audit-Trail:
From: Iain Hibbert <plunky@rya-online.net>
To: Tom Ivar Helbekkmo <tih@hamartun.priv.no>
Cc: gnats-bugs@netbsd.org, current-users@netbsd.org
Subject: Re: PR/45909: Use of MIDI over USB interfaces crashes NetBSD
Date: Sat, 4 Feb 2012 12:46:13 +0000 (GMT)

 On Wed, 1 Feb 2012, Tom Ivar Helbekkmo wrote:

 (I changed the subject btw and Cc'd gnats bugs so this should get attached
 to the PR)

 > 1: the kernel lock needs to be held while an input transfer is
 >    initiated (the KASSERT(KERNEL_LOCKED_P()) is found in the function
 >    usbd_transfer() in /sys/dev/usb/usbdi.c).  I added code to grab and
 >    release the kernel lock to open_in_jack() in /sys/dev/usb/umidi.c,
 >    around the call to start_input_transfer().

 this bit seems ok to me

 > 2: the kernel lock must, again, be held while a transfer is aborted
 >    (by calling usbd_abort_xfer()).  This happens while closing a MIDI
 >    interface that was open for reading, and midiclose(), in
 >    /sys/dev/midi.c, does not itself grab the lock.  Again, a KASSERT()
 >    fails for this situation.  I added code to grab and release the
 >    kernel lock to close_in_jack() in /sys/dev/usb/umidi.c.

 I think you meant usbd_abort_pipe() btw? but given that, seems ok..

 > 3: The softc spinlock mutex must *not* be held during the above
 >    mentioned call to usbd_abort_xfer(), but midiclose() does hold it
 >    while calling the umidi driver's closing function.  This fails
 >    because usbd_abort_xfer() wants to relinquish the CPU to allow the
 >    hardware time to catch up, and a context switch is then attempted
 >    with the mutex held.  I added code to release and re-grab the mutex
 >    around the call to usbd_abort_xfer() in /sys/dev/usb/umidi.c.

 I don't think its right to release/aquire a lock that a higher layer is
 holding to protect its access to the resource, since the resource can
 change from underneath it..

 and if usbd_abort_pipe() is relinquishing the CPU, what about the kernel
 lock?

 > 4: After a MIDI device that was open for read has been closed (with
 >    the above fixes in place), reopening it for read fails because of
 >    the state it is left in by usbd_abort_xfer().  Specifically, the
 >    first attempt to start an input transfer on it returns
 >    USBD_CANCELLED, reflecting the aborted transfer.  This is benign,
 >    and I simply added that return code to the set of those that are
 >    accepted as non-errors by the umidi driver.

 is there another way to fix this, so that CANCELLED is not returned? IIRC
 when I've used usbd_abort_pipe() I also closed the pipe and reopened it
 for the next use, not sure if that is actually required..

 > -int	umididebug = 0;
 > +int	umididebug = 1;

 that is unrelated :)

 >  #else
 >  #define DPRINTF(x)
 >  #define DPRINTFN(n,x)
 > @@ -255,6 +255,7 @@
 >  error:
 >  	aprint_error_dev(self, "disabled.\n");
 >  	sc->sc_dying = 1;
 > +	KERNEL_UNLOCK_ONE(curlwp);
 >  	return;

 and you didn't mention that (but it is needed :)

 > @@ -1415,12 +1430,17 @@
 >  static usbd_status
 >  start_input_transfer(struct umidi_endpoint *ep)
 >  {
 > +	usbd_status rv;
 > +
 > +	DPRINTFN(200,("umidi in transfer: start %p length %u\n",
 > +	    ep->buffer, ep->buffer_size));
 >  	usbd_setup_xfer(ep->xfer, ep->pipe,
 >  			(usbd_private_handle)ep,
 >  			ep->buffer, ep->buffer_size,
 >  			USBD_SHORT_XFER_OK | USBD_NO_COPY,
 >                          USBD_NO_TIMEOUT, in_intr);
 > -	return usbd_transfer(ep->xfer);
 > +	rv = usbd_transfer(ep->xfer);
 > +	return rv;
 >  }

 and this probably not needed?

 iain

 (I don't have any MIDI hardware btw, no way to test any of this :)


From: Tom Ivar Helbekkmo <tih@hamartun.priv.no>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,  gnats-admin@netbsd.org,  netbsd-bugs@netbsd.org
Subject: Re: PR/45909: Use of MIDI over USB interfaces crashes NetBSD
Date: Sat, 04 Feb 2012 15:45:39 +0100

 Iain Hibbert <plunky@rya-online.net> writes:

 >  I think you meant usbd_abort_pipe() btw? but given that, seems ok..

 Yes, of course.  :)

 >  I don't think its right to release/aquire a lock that a higher layer is
 >  holding to protect its access to the resource, since the resource can
 >  change from underneath it..

 Agreed.  It looks ugly as sin, too.  I just did what I could with
 umidi.c alone - I didn't want to start messing with higher level code,
 in case I broke something for other drivers.  For all I know, it's
 possible that the thread lock could be released in midiclose(), before
 the hw->close() call, since I suspect that it's really only needed for
 the while() { cv_wait() } loop...?

 >  and if usbd_abort_pipe() is relinquishing the CPU, what about the kernel
 >  lock?

 Yeah, I don't understand that bit at all.  You get a KASSERT failure if
 you call usbd_abort_pipe() without holding the kernel lock, though - and
 another one if you *are* holding the thread lock, when it tries to do a
 context change with a mutex held.  This challenges my understanding of
 what the kernel lock is.  :)

 >  is there another way to fix this, so that CANCELLED is not returned? IIRC
 >  when I've used usbd_abort_pipe() I also closed the pipe and reopened it
 >  for the next use, not sure if that is actually required..

 You mean call usbd_abort_pipe(), usbd_close_pipe() and usbd_open_pipe()
 in sequence within close_in_jack()?

 >  > -int	umididebug = 0;
 >  > +int	umididebug = 1;
 >  
 >  that is unrelated :)

 Yeah - but it's silly to have it set to 0, since then just building a
 kernel with the UMIDI_DEBUG option doesn't give you any debug output,
 which IMHO breaks the Principle of Least Astonishment.

 >  >  #else
 >  >  #define DPRINTF(x)
 >  >  #define DPRINTFN(n,x)
 >  > @@ -255,6 +255,7 @@
 >  >  error:
 >  >  	aprint_error_dev(self, "disabled.\n");
 >  >  	sc->sc_dying = 1;
 >  > +	KERNEL_UNLOCK_ONE(curlwp);
 >  >  	return;
 >  
 >  and you didn't mention that (but it is needed :)

 Ah, yes.  Someone must have forgotten to put it in at some time, and I
 fixed it when I noticed it.

 >  > @@ -1415,12 +1430,17 @@
 >  >  static usbd_status
 >  >  start_input_transfer(struct umidi_endpoint *ep)
 >  >  {
 >  > +	usbd_status rv;
 >  > +
 >  > +	DPRINTFN(200,("umidi in transfer: start %p length %u\n",
 >  > +	    ep->buffer, ep->buffer_size));
 >  >  	usbd_setup_xfer(ep->xfer, ep->pipe,
 >  >  			(usbd_private_handle)ep,
 >  >  			ep->buffer, ep->buffer_size,
 >  >  			USBD_SHORT_XFER_OK | USBD_NO_COPY,
 >  >                          USBD_NO_TIMEOUT, in_intr);
 >  > -	return usbd_transfer(ep->xfer);
 >  > +	rv = usbd_transfer(ep->xfer);
 >  > +	return rv;
 >  >  }
 >  
 >  and this probably not needed?

 Heh, no.  Forgot about that.  It's left over from an experiment that
 didn't go anywhere useful.  :)

 -tih
 -- 
 "The market" is a bunch of 28-year-olds who don't know anything. --Paul Krugman

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        tih@hamartun.priv.no
Subject: Re: PR/45909: Use of MIDI over USB interfaces crashes NetBSD
Date: Sat, 4 Feb 2012 17:36:27 +0100

 On Sat, Feb 04, 2012 at 02:50:04PM +0000, Tom Ivar Helbekkmo wrote:
 >  Yeah, I don't understand that bit at all.  You get a KASSERT failure if
 >  you call usbd_abort_pipe() without holding the kernel lock, though - and
 >  another one if you *are* holding the thread lock, when it tries to do a
 >  context change with a mutex held.  This challenges my understanding of
 >  what the kernel lock is.  :)

 the kernel lock is much more than a simple mutex (there's a refcount so
 it can be reentrant, for example). When the kernel is going to sleep,
 the kernel lock is released and reaquired on wakeup.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: "Iain Hibbert" <plunky@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45909 CVS commit: src/sys/dev/usb
Date: Tue, 7 Feb 2012 11:40:24 +0000

 Module Name:	src
 Committed By:	plunky
 Date:		Tue Feb  7 11:40:24 UTC 2012

 Modified Files:
 	src/sys/dev/usb: umidi.c

 Log Message:
 two locking fixes (from PR/45909)

 - during attach, release kernel lock in error path
 - during midiopen, take kernel lock for USB activity

 (there are more problems with locking here, this does not fix the PR)


 To generate a diff of this commit:
 cvs rdiff -u -r1.55 -r1.56 src/sys/dev/usb/umidi.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: kern-bug-people->mrg
Responsible-Changed-By: mrg@NetBSD.org
Responsible-Changed-When: Sat, 18 Feb 2012 04:11:36 +0000
Responsible-Changed-Why:
i've modified umidi for the MP audio changes


State-Changed-From-To: open->feedback
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Sat, 18 Feb 2012 04:11:36 +0000
State-Changed-Why:
i think this is all fixed now.  can you confirm?  thanks.


From: Tom Ivar Helbekkmo <tih@hamartun.priv.no>
To: gnats-bugs@netbsd.org
Cc: mrg@NetBSD.org,  kern-bug-people@netbsd.org,  netbsd-bugs@netbsd.org,  gnats-admin@netbsd.org
Subject: Re: kern/45909 (Use of MIDI over USB interfaces crashes NetBSD)
Date: Sun, 19 Feb 2012 12:51:50 +0100

 mrg@NetBSD.org writes:

 > i think this is all fixed now.  can you confirm?  thanks.

 It doesn't crash now, but it doesn't entirely work, either.  Reading
 from USB MIDI works fine, but writing, although not flagging any errors,
 doesn't work: nothing ever hits the synth.  My Roland UM-ONE interfaces
 have tx and rx LEDs, and with the new umidi driver, the tx LEDs stay
 dark during, say, 'midiplay -d [0|1] -x'.  (Everything worked while I
 was running the previous version with my modifications.)

 -tih
 -- 
 "The market" is a bunch of 28-year-olds who don't know anything. --Paul Krugman

From: Tom Ivar Helbekkmo <tih@hamartun.priv.no>
To: gnats-bugs@netbsd.org
Cc: mrg@NetBSD.org,  gnats-admin@netbsd.org,  netbsd-bugs@netbsd.org
Subject: Re: kern/45909 (Use of MIDI over USB interfaces crashes NetBSD)
Date: Sun, 19 Feb 2012 13:30:05 +0100

 I wrote:

 >  It doesn't crash now, but it doesn't entirely work, either.  Reading
 >  from USB MIDI works fine, but writing, although not flagging any errors,
 >  doesn't work: nothing ever hits the synth.

 Right, that was easily fixed.  I see you're making everything observe
 mididev->closing to avoid having to lock things, but you've accidentally
 reversed the sense of this flag in the writing routines.

 Works fine with the appended patch.

 -tih

 Index: umidi.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/usb/umidi.c,v
 retrieving revision 1.59
 diff -u -r1.59 umidi.c
 --- umidi.c	14 Feb 2012 19:28:22 -0000	1.59
 +++ umidi.c	19 Feb 2012 12:28:38 -0000
 @@ -391,7 +391,7 @@
  {
  	struct umidi_mididev *mididev = addr;

 -	if (!mididev->out_jack || !mididev->opened || !mididev->closing)
 +	if (!mididev->out_jack || !mididev->opened || mididev->closing)
  		return EIO;

  	return out_jack_output(mididev->out_jack, msg, len, (status>>4)&0xf);
 @@ -403,7 +403,7 @@
  	struct umidi_mididev *mididev = addr;
  	int cin;

 -	if (!mididev->out_jack || !mididev->opened || !mididev->closing)
 +	if (!mididev->out_jack || !mididev->opened || mididev->closing)
  		return EIO;

  	switch ( len ) {
 @@ -422,7 +422,7 @@
  	struct umidi_mididev *mididev = addr;
  	int cin;

 -	if (!mididev->out_jack || !mididev->opened || !mididev->closing)
 +	if (!mididev->out_jack || !mididev->opened || mididev->closing)
  		return EIO;

  	switch ( len ) {
 @@ -441,7 +441,7 @@
  	struct umidi_mididev *mididev = addr;
  	u_char msg = d;

 -	if (!mididev->out_jack || !mididev->opened || !mididev->closing)
 +	if (!mididev->out_jack || !mididev->opened || mididev->closing)
  		return EIO;

  	return out_jack_output(mididev->out_jack, &msg, 1, 0xf);

 -- 
 "The market" is a bunch of 28-year-olds who don't know anything. --Paul Krugman

From: matthew green <mrg@eterna.com.au>
To: Tom Ivar Helbekkmo <tih@hamartun.priv.no>
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
    gnats-admin@netbsd.org, gnats-bugs@netbsd.org
Subject: re: kern/45909 (Use of MIDI over USB interfaces crashes NetBSD)
Date: Mon, 20 Feb 2012 07:05:37 +1100

 > mrg@NetBSD.org writes:
 > 
 > > i think this is all fixed now.  can you confirm?  thanks.
 > 
 > It doesn't crash now, but it doesn't entirely work, either.  Reading
 > from USB MIDI works fine, but writing, although not flagging any errors,
 > doesn't work: nothing ever hits the synth.  My Roland UM-ONE interfaces
 > have tx and rx LEDs, and with the new umidi driver, the tx LEDs stay
 > dark during, say, 'midiplay -d [0|1] -x'.  (Everything worked while I
 > was running the previous version with my modifications.)

 hmmm.  i was seeing this as well, but when i tried to traack it down
 the problem disappeared for me, i built a bunch of kernels going back
 about a month - when i last tested it worked.

 but now it's failing for me again, too.  investigating more now.

 can you confirm that the previous version with your patches was
 against umidi 1.55?  do you know the date of the rest of the
 that tree?

 thanks.


 .mrg.

From: matthew green <mrg@eterna.com.au>
To: Tom Ivar Helbekkmo <tih@hamartun.priv.no>
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
    gnats-bugs@netbsd.org
Subject: re: kern/45909 (Use of MIDI over USB interfaces crashes NetBSD)
Date: Mon, 20 Feb 2012 07:11:16 +1100

 > Right, that was easily fixed.  I see you're making everything observe
 > mididev->closing to avoid having to lock things, but you've accidentally
 > reversed the sense of this flag in the writing routines.
 > 
 > Works fine with the appended patch.

 oh good catch!  thanks.

From: "matthew green" <mrg@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45909 CVS commit: src/sys/dev/usb
Date: Sun, 19 Feb 2012 20:20:31 +0000

 Module Name:	src
 Committed By:	mrg
 Date:		Sun Feb 19 20:20:31 UTC 2012

 Modified Files:
 	src/sys/dev/usb: umidi.c

 Log Message:
 fix the reversed logic in several uses of the new 'closing' member
 introduced in the previous change.

 from Tom Ivar Helbekkmo <tih@hamartun.priv.no> in PR 45909.  thanks!


 To generate a diff of this commit:
 cvs rdiff -u -r1.59 -r1.60 src/sys/dev/usb/umidi.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "matthew green" <mrg@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45909 CVS commit: [jmcneill-usbmp] src/sys/dev/usb
Date: Sun, 19 Feb 2012 21:01:52 +0000

 Module Name:	src
 Committed By:	mrg
 Date:		Sun Feb 19 21:01:52 UTC 2012

 Modified Files:
 	src/sys/dev/usb [jmcneill-usbmp]: umidi.c

 Log Message:
 pullup umidi.c 1.60:
 >fix the reversed logic in several uses of the new 'closing' member
 >introduced in the previous change.
 >
 >from Tom Ivar Helbekkmo <tih@hamartun.priv.no> in PR 45909.  thanks!


 To generate a diff of this commit:
 cvs rdiff -u -r1.53.2.2 -r1.53.2.3 src/sys/dev/usb/umidi.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Stephen Borrill" <sborrill@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45909 CVS commit: [netbsd-6] src/sys/dev/usb
Date: Mon, 20 Feb 2012 21:16:59 +0000

 Module Name:	src
 Committed By:	sborrill
 Date:		Mon Feb 20 21:16:59 UTC 2012

 Modified Files:
 	src/sys/dev/usb [netbsd-6]: umidi.c

 Log Message:
 Pull up the following revisions(s) (requested by mrg in ticket #12):
 	sys/dev/usb/umidi.c:	revision 1.60

 Fix the reversed logic in several uses of the new 'closing' member
 introduced in the previous change. From PR 45909.


 To generate a diff of this commit:
 cvs rdiff -u -r1.59 -r1.59.2.1 src/sys/dev/usb/umidi.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: feedback->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Tue, 06 Mar 2012 16:55:08 +0000
State-Changed-Why:
confirmed fixed - thanks for the report!


From: Tom Ivar Helbekkmo <tih@hamartun.priv.no>
To: gnats-bugs@netbsd.org
Cc: mrg@NetBSD.org,  gnats-admin@netbsd.org,  netbsd-bugs@netbsd.org
Subject: Re: kern/45909 (Use of MIDI over USB interfaces crashes NetBSD)
Date: Tue, 06 Mar 2012 17:53:34 +0100

 Tom Ivar Helbekkmo <tih@Hamartun.Priv.NO> writes:

 > Works fine with the appended patch.

 I'm getting reminders that this issue is waiting for my feedback.  It's
 still working just fine for me, and since mrg has committed the patch I
 sent, I can definitely confirm that the bug is no more, and the ticket
 can safely be closed.  :)

 -tih
 -- 
 Self documenting code isn't. User application constraints don't. --Ed Prochak

>Unformatted:

Home	PR Database Search