On Fri, May 18, 2001 at 08:26:48PM -0400, Dan Streetman wrote:
> >Short answer is "too confusing". I am sure Dan did a due dilligence
> >looking at code paths and yet he blew it (I would too...).
> >The fact that the technique is unconventional does not help.
>
> I can't see why the urb's spinlock is being held at all at that point,
> especially if it's going to be possibly freed.
The lock saves the URB from parallel deletion in the unlink_urb-functions on
SMP. There is already a urb_list_lock that can do this globally, but
urb_list_lock has to be released before the completion to allow further
submit_urb-calls in the completion. So in the completion only the related
URB is locked.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
