Skip site navigation (1)Skip section navigation (2)
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>