On Mon, 24 Oct 2011, Adam Kropelin wrote: > On Sun, Oct 23, 2011 at 7:05 AM, Albert Herranz <albert_herranz@xxxxxxxx> wrote: > > Adam Kropelin <akropel1@...> writes: > >> > >> I'm encountering a recursive lock scenario in the usbnet urb unlink > >> path (triggered by 'ifconfig X down'). This is one of those cases > >> where I must be misunderstanding something because if my analysis is > >> correct everyone would be having this problem, not just me. > > > > You're not alone. > > Excellent...so I'm not completely insane, at least not this time. > > > http://gc-linux.git.sourceforge.net/git/gitweb.cgi?p=gc-linux/gc-linux- > > 2.6.git;a=commitdiff;h=23fe8f8c2eac65e665e1f39a41674bd2d52e42c4 > > I considered that approach but it seemed dangerous to simply drop the > queue lock while traversing the list. If another urb were to complete > during the window where the lock is dropped, the unlink traversal > would go off in the weeds since the the queue would be modified > underneath it. I guess your approach to prevent that is to leave irqs > disabled while the queue unlocked. But we already know urb completion > callbacks aren't required to come from interrupt context, so is that > sufficient protection? The usual approach in these situations is to drop the lock before doing the unlink. In general unlinks are done in reverse order (to avoid sending data with gaps in it), but in this case that may not matter. It will however be necessary to mark each skb_data when unlinking it. What you do is look through the queue for the last (or first) unmarked entry, mark it, drop the lock, and unlink it. Then go back to the start and repeat, until there are no unmarked entries remaining. 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
