On Mon, 6 Apr 2009, Ming Lei wrote: > >> 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. > > usb_serial_port structure is freed in destroy_serial(), which is only called if > the reference count of usb_serial is zero. Yes, and this is wrong. My patch changes this; it causes the usb_serial_port structure to be freed when its refcount goes to 0. > > 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. > > If usb_serial_disconnect() has returned, usb_autopm_get_interface() may > return a failure, and serial_open can process the case. But usb_autopm_get_interface() might _not_ return a failure, because the device may still be plugged in. > >> 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). > > I guess it is the tty_hangup( called by usb_serial_disconnect),which can > cause mutex_lock_interruptible() to return a failure. Does tty_hangup() always interrupt a task? What if the task has blocked signals? 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
