On Mon, 6 Apr 2009, Ming Lei wrote: > 2009/4/5 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > > > > BTW, I'm concerned about that usb-serial.c patch posted earlier. In > > what is the purpose of the patch? which fixes? The purpose of the patch is to fix the bug reported here: http://bugs.freedesktop.org/show_bug.cgi?id=20703 The bug is that the usb_serial and usb_serial_port structures are not reference-counted correctly. > > particular, does serial_open() hold disc_mutex long enough? What > > IMHO, it is not a kind of open/disconnect race, serial_port_open() is more > proper than serial_open(). What are you talking about? There is no serial_port_open() routine in drivers/usb/serial, nor anywhere else I know of. > Once usb_serial_get_by_index() returns a non NULL > serial, the port device doesn't disappear even if the usb serial > device is disconnected. First of all, this doesn't make sense. usb_serial_get_by_index() returns a pointer to the usb_serial structure, not to the port device. So the usb_serial structure won't disappear, but there's nothing to prevent the usb_serial_port structure from disappearing. Second, none of this matters since I'm not concerned about whether the port device disappears. Rather, I'm concerned about whether serial_open() can call usb_autopm_get_interface() after usb_serial_disconnect() has returned. That should never happen. > So, maybe holding disc_mutex in serial_open is not necessary. > > > happens if a disconnect occurs while serial_open() is waiting to > > acquire port->mutex? Do you think the calls to > > mutex_lock_interruptible() should return a failed value. Why shoult it? The only reason mutex_lock_interruptible() ever returns a failure is if the task gets interrupted (for example, the user presses ^C). Alan Stern -- 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
