On Tue, Jul 28, 2009 at 12:31:20AM +0100, Alan Cox wrote: > On Mon, 27 Jul 2009 14:46:35 -0400 (EDT) > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > [CC: list trimmed] > > > > Alan: > > > > I just tried testing this under 2.6.31-rc4 plus > > gregkh-all-2.6.31-rc4.patch, and the results were pretty nasty. All I > > did was plug in my pl2303-based USB serial device and type "cat > > /dev/ttyUSB0". > > > > In serial_open(), the call to tty_port_block_til_ready() returned > > -512, whatever that means. The error path at the end of serial_open() > > then failed because it tried to release some mutexes that had already > > been released. Okay, I fixed that, and then tty_open() died trying to > > access deallocated memory. > > > > Do you have any idea what's going on or should I look more closely? > > I think this should whack the remaining usb serial problems. The > tty_vhangup change I'll defer - its not critical and it's a late -rc. The > other stuff should fix the both the port number leak and the crash - > which was hidden by the other tty_port_block_until_wait bug when I was > testing this stuff. > > Gak, pass the paper bags. Ick, that's horrible :) > commit 3f40612e940971ecec29d5375cdcc9f9c9a9f46e > Author: Alan Cox <alan@xxxxxxxxxxxxxxx> > Date: Tue Jul 28 00:23:39 2009 +0100 > > tty: USB lock/refcounting fixes > > This fixes > - locking bug that was hidden by ecc2e05e739c30870c8e4f252b63a0c4041f2724 > - Regression #13821 > - Spurious warning when closing and blocking for data write out > > With these changes my PL2303 always ends up as ttyUSB0 when it should and > the module refcounts stay correct. > > I'll do a more wholesale split & tidy of _open in the next release or two > as we get a standard tty_port_open and port->ops->init port->ops->shutdown > call backs. That will be much nicer to have. Thanks for finding this, and for doing all of the tty layer work overall. It's much appreciated and needed. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
