> From: Georg Acher <[EMAIL PROTECTED]>
> Date: Sat, 19 May 2001 15:54:39 +0200
>
> 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.
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 only way to get around that is to never let it happen,
e.g. you free or call something that can free without any
locks; you protect from parallel access by your data
structures, e.g. list membership. [I mean "only reasonable
way", because you can also use off-object lock to close the
whole subsystem while you delete listed stuff.]
-- Pete
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
