On Mon, 25 Nov 2013, Xenia Ragiadakou wrote: > On 11/25/2013 01:50 AM, Xenia Ragiadakou wrote: > > [snip] > >> Also, while you're going through the whole remove-and-add procedure for > >> endpoints that aren't halted, do you want to hold the bandwidth mutex? > >> If the procedure isn't atomic, there's a possibility that some other > >> device could change configs in the middle. This would also prevent > >> concurrent altsetting changes. > > > > Yes, i need to lock the bandwidth_mutex. I will fix this. > > > >> Alan Stern > > After i looked at it more carefully, there will be a deadlock if i try > to aqcuire the bandwidth_mutex in reset endpoint code. > In usb_set_configuration(), the bandwidth_mutex is held while > usb_enable_interface() is called for each interface and > usb_enable_interface() will attempt to reset the endpoints via > usb_enable_endpoint() since the 3rd argument is set to true. > So, I think it's not a good idea to try to lock the bandwidth_mutex > given that, right? Right. We don't have to worry about config changes anyway, because the config can't be changed until all the old endpoints are disabled. You just have to make sure that an endpoint can't be disabled until a pending reset is finished. 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
