Date: Mon, 25 Jun 2007 06:40:21 +0000 (UTC) From: Warner Losh <imp@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/dev/usb ucom.c Message-ID: <200706250640.l5P6eLt8077997@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
imp 2007-06-25 06:40:20 UTC
FreeBSD src repository
Modified files:
sys/dev/usb ucom.c
Log:
Starting in version 1.56, ucomstop started calling ucomstart to work
around an output freezing problem (see the CVS log for details). This
is the same approach that sio takes to solve that problem. However,
ucom has a problem that sio doesn't have.
Consider the case where output is pending, and the device is closed.
ttyclose calls tt_close (which indirects to ucomclose) and then calls
ttyflush which calls tt_stop (which indirects to ucomstop). Since
ucomclose removed all the usb transfer points, sc_oxfer will be NULL
when ucomstop calls ucomstart. This results in a null pointer
dereference.
Since calling ucomstart in ucomstart solves other problems, we need to
work with this calling sequence. The easiest way to do that is to
bail early if sc_oxfer is NULL.
Kazuaki ODA-san came up with this patch, and filed a PR. I had seen
this bug at work and this patch does seem to solve it. He had no idea
why it worked, but knew that either this patch, or backing out ucom.c
1.56 fixed his panic. I just did the legwork of chasing down the code
paths that would cause this, and added a comment. This is obscure
enough to warrant a comment, I think.
Submitted by: Kazuaki ODA-san
PR: 113964
Approved by: re (bmah)
Revision Changes Path
1.64 +10 -0 src/sys/dev/usb/ucom.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706250640.l5P6eLt8077997>