From owner-freebsd-usb@FreeBSD.ORG Sun Jun 24 06:50:08 2007 Return-Path: X-Original-To: freebsd-usb@hub.freebsd.org Delivered-To: freebsd-usb@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F3AC16A400 for ; Sun, 24 Jun 2007 06:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 12D6513C44B for ; Sun, 24 Jun 2007 06:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5O6o7p3040735 for ; Sun, 24 Jun 2007 06:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5O6o7CZ040728; Sun, 24 Jun 2007 06:50:07 GMT (envelope-from gnats) Date: Sun, 24 Jun 2007 06:50:07 GMT Message-Id: <200706240650.l5O6o7CZ040728@freefall.freebsd.org> To: freebsd-usb@FreeBSD.org From: "M. Warner Losh" Cc: Subject: Re: usb/113964: [patch] ucom(4): kernel panic when dropping a connection X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "M. Warner Losh" List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2007 06:50:08 -0000 The following reply was made to PR usb/113964; it has been noted by GNATS. From: "M. Warner Losh" To: kazuaki@aliceblue.jp Cc: FreeBSD-gnats-submit@FreeBSD.ORG, re@FreeBSD.ORG Subject: Re: usb/113964: [patch] ucom(4): kernel panic when dropping a connection Date: Sun, 24 Jun 2007 00:48:08 -0600 (MDT) In message: <467D7AE6.2090302@aliceblue.jp> Kazuaki ODA writes: : M. Warner Losh wrote: : > In message: <200706231136.l5NBa61H001748@eyes.aliceblue.jp> : > Kazuaki ODA 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. I think that the problem is the addition of ucomstart() at the end of ucomstop(). I think that the tty layer calls t_stop() as part of the ttyflush() routine. ttyflush() is called inside of tty_close(), which is called after the tt_close() call in ttyclose(). The addition appears to have been taken from sio, either directly, or at the recommendation of Bruce. The sio routines are written such that the close doesn't delete data that's referenced later. In our case, it is the right thing to do in ucomclose(), so we need to guard against it later when the data might be used. Since ucom chose to have ucomstart() called from ucomstop(), I think it is up to ucom to guard against known calling paths. I think this is not only a good workaround, therefore, but may be a correct fix on its own merit. Warner P.S. I'm not sure that I got my head wrapped around code that uses ttyfoo(), tty_foo() and tt_foo(), but I sure hope so.