usb/113964: [patch] ucom(4): kernel panic when dropping a connection

[M. Warner Losh]

The following reply was made to PR usb/113964; it has been noted by GNATS.

From: "M. Warner Losh" <imp at bsdimp.com>
To: kazuaki at aliceblue.jp
Cc: FreeBSD-gnats-submit at FreeBSD.ORG
Subject: Re: usb/113964: [patch] ucom(4): kernel panic when dropping a
 connection
Date: Sun, 24 Jun 2007 00:14:21 -0600 (MDT)

 In message: <467D7AE6.2090302 at aliceblue.jp>
             Kazuaki ODA <kazuaki at aliceblue.jp> writes:
 : M. Warner Losh wrote:
 : > In message: <200706231136.l5NBa61H001748 at eyes.aliceblue.jp>
 : >             Kazuaki ODA <kazuaki at aliceblue.jp> writes:
 : > : 	I don't know the proper fix but the following patch is workaround for
 : > : 	me.
 : > : 
 : > : --- ucom.c.patch begins here ---
 : > : --- sys/dev/usb/ucom.c.orig	2007-06-22 23:45:37.000000000 +0900
 : > : +++ sys/dev/usb/ucom.c	2007-06-23 17:47:18.000000000 +0900
 : > : @@ -532,6 +532,9 @@
 : > :  	if (sc->sc_dying)
 : > :  		return;
 : > :  
 : > : +	if (sc->sc_oxfer == NULL)
 : > : +		return;
 : > : +
 : > :  	s = spltty();
 : > :  
 : > :  	if (tp->t_state & TS_TBLOCK) {
 : > : --- ucom.c.patch ends here ---
 : > 
 : > This is a good workaround.  However, why does the tty->t_oproc get
 : > called after the tty->t_close routine which sets sc->sc_oxfer to NULL?
 : > 
 : > Warner
 : 
 : Unfortunately, I have no idea.  But it seems the changes of tty 
 : subsystem and ucom.c rev. 1.56 are related to the issue.
 : 
 : * On 5.x-RELEASE, where ucom.c rev. 1.56 has been MFCed, we get no panic.
 : 
 : * On 6.x-RELEASE or 7.0-CURRENT, we get a panic.
 : 
 : * After backing out ucom.c rev. 1.56, no panic on 6.x-RELEASE or 
 : 7.0-CURRENT.
 
 OK.  This is an important hint.  However, it will take a while to
 study it.
 
 Warner