On Tue, 2014-09-02 at 11:39 -0400, Alan Stern wrote:
> The way resets are carried out is also changed. Now the driver will
> call usb_queue_reset_device() instead of calling usb_reset_device()
> directly. This avoids a deadlock that would arise when a device is
> unplugged: The hid_reset() routine runs as a workqueue item, a reset
> attempt after the device has been unplugged will fail, failure will
> cause usbhid to be unbound, and the disconnect routine will try to do
> cancel_work_sync(). The usb_queue_reset_device() implementation is
> carefully written to handle scenarios like this one properly.
Hi,
it seems to me that this way you race with close(). hid_post_reset()
will call hid_start_in() unconditionally. usbhid_close() will call
hid_cancel_delayed_stuff(), but this is no longer enough, if you use
usb_queue_reset_device(), as the reset may still proceed.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
