Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use

Alan Stern
2009-08-19T18:20:27Z

On Wed, 19 Aug 2009, Bruno [UTF-8] PrÃ©mont wrote:

> I did try to understand what happens exactly, using backtrace from
> kernel compiled with debug info and running objdump on usbserial.ko.

> Verifying by adding a few printk()'s inside serial_do_free() confirms my
> understanding of the objdump and also tells me that after unplug
> serial_do_free() is called twice (with different addresses for port->serial->type)!

In fact, with different values for port->serial. Probably because port
was deallocated before the second call occurred.

> The first one (right after unplug) survives, the second one (when exiting
> minicom) crashes.
>
> Extract from the logs with my printk()'s
> [ 266.290632] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
> [ 266.290938] ftdi_sio 2-2:1.1: device disconnected
> [ 266.292378] tty_port_close_start: count = -1
> [ 266.292535] serial_do_free(port @da0d9000)
> [ 266.292692] serial @da3e9840
> [ 266.292791] type @deb45660
> /* exit minicom */
> [ 290.728196] serial_do_free(port @da0d9000)
> [ 290.728341] serial @da0d9200
> [ 290.728461] type @3a6e6967
> [ 290.728591] BUG: unable to handle kernel paging request at 3a6e6983
> [ 290.728823] IP: [<deb02d5d>] serial_do_free+0x6d/0xd0 [usbserial]

> Printk's were added:
>
> if (port->console)
> return;
> /* here */
> serial = serial->port;
> owner = serial->type->driver.owner /* crash here */
>
> Is it useful to check calls to serial_do_free() for my pl2303
> usb2serial converter? (e.g. to compare behavior from both of them)

You could try; it wouldn't hurt. More useful would be to add some
debugging messages to destroy_serial(). There should not be any calls
to serial_do_free() after destroy_serial() runs.

Also add some messages to the places that call usb_serial_put() and
usb_serial_get_by_index().

Alan Stern