Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Mon, 23 Jul 2012, Bjørn Mork wrote: > >> >>>[ 243.148375] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 >> >>>[ 243.148471] BUG: unable to handle kernel NULL pointer dereference at (null) >> >>>[ 243.148508] IP: [<ffffffffa0468527>] stop_read_write_urbs+0x37/0x80 [usb_wwan] >> >> Yes, this is easily reproducible with any driver based on usb_wwan. >> I've tested both qcserial and option. The immediate cause of this is >> that the &port->dev drvdata is NULL when stop_read_write_urbs is called, >> so that >> >> portdata = usb_get_serial_port_data(port); >> >> ends up being NULL. This problem can also hit in resume I believe. I >> think some of the solution may be moving device_del from disconnect to >> destroy (cut'n paste patch - probably white space damaged): > > No, that's definitely not the way to go. Yes, I suspected that was just papering over part of the problem.. > I suspect that answer is to make usb_wwan_disconnect a .port_remove > callback instead of a .disconnect callback. By the time the disconnect > method runs, the ports have been unregistered and are basically gone. I have a hard time trying to figure out the logic in usb_wwan. There is the usb_wwan_release which is called from destroy_serial, attempting to access and free driver specific serial_port_data. And there is the usb_wwan_disconnect which is called from the USB driver disconnect, and will attempt to kill a number of urbs stored in the serial_port_data. This seems a bit backwards, and AFAICS both of these must expect to be called after the port is gone. Should both be merged and converted to a .port_remove callback? That does seem sanest, given that they operate on port data. Bjørn -- 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
