On Sat, May 19, 2001 at 11:59:29AM -0400, Pete Zaitcev wrote:
> > 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.
>
> You cannot rely on an in-object spinlock in order to
> protect from deletion. Suppose you locked something for
> that reason, an object with internal lock, on CPU0.
> Then CPU2 spins on that spinlock somehow. Now, there
> is absolutely no way for you to unlock the object right
> on CPU0. If you free while CPU2 is spinning on the lock,
> you panic the system (some implementations may forgive you,
> but don't count on it). If you unlock before you free,
> you are in the square one again because CPU2 will get unstuck
> immediately and race you for the access to the object.
The point is not to prevent it from being deleted, the construction simply
blocks the deletion of that specific URB if the completion is running.
Afterwards it can be deleted.
Please note sequence of the lock/unlock-calls for urb->lock und
urb_list_lock in process_urb() and unlink_urb():
process_urb:
LOCK(urb->lock)
UNLOCK(urb_list_lock)
completion-handler()
LOCK(urb_list_lock)
UNLOCK(urb->lock)
Here the urb may be modified/freed by another process, to don't touch it
anymore if it was a single (not-resubmitted) urb.
unlink_urb:
LOCK_IRQSAVE(urb_list_lock)
LOCK(urb->lock)
...
UNLOCK(urb->lock)
UNLOCK_IRQRESTORE(urb_list_lock)
--
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
