On Monday 14 January 2002 18:56, David Brownell wrote:
> My original description of the race was:
> > there's ALWAYS a race on SMPs between completion handler
> > finishing with that URB, and other driver code reusing it.
>
> In more detail, HCD code on some CPU will set the "flag" value,
> probably a short while before it calls the completion handler.
> Starting at that instant, device driver code running any other CPU
> could test it, and conclude (falsely) that the urb is reusable.
>
> But that flag will be set before the completion function is invoked,
> and certainly before it's finished. Ergo, race on SMP.
>
> URBs can only be reused after the completion handler finishes.
> In the skeleton driver, that wouldn't break much, except it'd cause
> a false diagnostic -- but drivers derived from it would normally
> do real work in those handlers.
David,
that makes no sense.
There's no need at all to set a flag/increment a counter in the HCD.
The usbcore can easily do this as early as usb_submit_urb().
All you may have to add is the proper smp-aware primitive to push
that change to all CPUs.
In the isr, which calls the completion handler, the flag is _cleared_ /
counter decremented, _after_ the completion handler. The isr will do
this last, just before return from interrupt.
The only race you could get is that on another CPU you might see
the urb as still in use. That you _must_ be able to deal with under
any concivable scheme.
You might even add a pointer to a waitqueue to the urb structure
to be woken by the HCD code after clearing the flag. No race at all
and some drivers could move all of their completion handlers out
of interrupt context.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
