> From: David Brownell <[EMAIL PROTECTED]>
> Date: Mon, 04 Jun 2001 19:22:47 -0700
> > The best way, IMHO, would be to prohibit it altogether.
> > E.g. if URB is submitted (returned from usb_submit_urb
> > successfuly), then it cannot be unlinked until completition
> > is called [see note about cancel below].
>
> Pete, if that's effectively suggesting that usb_unlink_urb()
> be removed from the API, I think that proposal is basically
> a nonstarter ... so I hope that's not what you mean to say! :)
OK, I see what you mean. My mistake.
> > Based on the above, I think that unlinking and completition
> > cannot work together as long as they abuse urb->status to signal
> > if the urb is referenced.
>
> If access or modification of urb->status were consistently
> protected by grabbing urb->lock, I'd think that suffices.
We do not hold the urb->lock in other HCs across urb->complete(),
so holding it in usb-uhci is a mistake. Right?
Once this is settled, imagine this: CPU1 is in process_urb,
takes list_lock and urb->lock, cleans status; CPU2 enters unlink_urb,
spins on list_lock. CPU1 drops list_lock, drops urb->lock,
and gets delayed by an interrup or something right before
a call to completition. CPU2 gets unstuck and seeing
clean status, frees the URB. CPU1 returns to call the
completition and oopses because urb->completiton is garbage now.
-- Pete
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
