On Mon, 20 Feb 2012, Sebastian Andrzej Siewior wrote: > On 02/20/2012 05:21 PM, Oliver Neukum wrote: > >> defer_bh() takes the lok which is hold during unlink_urbs(). The safe > >> walk suggest that the skb will be removed from the list and this is done > >> by defer_bh() so it seems to be okay to drop the lock here. > > > > I am afraid there's something wrong in the hcd driver. Async unlink must > > be possible with a lock held. I cannot approve this patch. > > Hmmm. The comment above unlink() says that. Looking through other hcds > it seems that musb is not the only one doing it wrong. Oh well... What's the issue here? If a driver calls usb_unlink_urb() while holding a lock, and the completion routine tries to acquire the same lock, then deadlock is possible. The fact that usb_unlink_urb() is asynchronous is not a guarantee of anything; the HCD is allowed to call the completion handler from within usb_unlink_urb(). It's true that the kerneldoc for usb_unlink_urb() says "This request is always asynchronous". It might be a good idea to remove the word "always", because it seems to give people the wrong idea. 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
