> > > 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?
If it's available for device driver use, yes. Otherwise no. But so
far as I know, it's not available for device driver use. No docs
say it's available, and grepping "urb->lock" suggests only the
HCDs use that field.
> 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.
I'm still trying to avoid knowing usb-uhci, so I won't
try to bugfix that example ... :)
Either the urb should unlink, OR the completion should
get called. CPU1 needed to mark (or hide) the URB so
that unlinking would fail ... it didn't. (And there's more
that seems wrong too, but that's a start.) Unlinking is
necessary, but messy.
There needs to be a state in the HCD where an URB
can no longer be unlinked because it's now on the way
back to the device driver. I mentioned what EHCI is
using since I think (hope!) that's a clean enough framework
to build on. I think OHCI should drop into that framework
pretty easily (fixing at least one race nobody's hit on yet :),
but UHCI needs more thought.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
