Oliver Neukum wrote:
> Am Dienstag, 17. September 2002 19:44 schrieb David Brownell:
>
>>>If I unlink my urbs upon disconnect synchronously and resubmit my urbs
>>>in the completon handler, is there a race condition between the two?
>>
>>Don't EVER submit another urb after you've gotten a disconnect()
>>callback -- that'd be a bug in your driver. Your disconnect logic
>>needs to arrange (first thing!) that no more urbs get submitted.
>
>
> There's quite subtle a problem here.
> In principle disconnect() is not SMP-safe at present by design.
The "not SMP-safe" seems more related to module unloading than
to the semantics of disconnect(). Don't scare the newbie ... ;)
And it's worth emphasizing that it doesn't affect the truth of
what I said: submitting after disconnect() is called is Wrong.
One with a REALLY EASY SOLUTION: every usb driver needs a
way to flag the "device is gone" state, and the disconnect()
callback has to (lock appropriately and) set that state very
early. Before submitting urbs, (lock and) check that state.
(Just like: before opening device, make sure it's there!
Which every driver has to be doing already.)
EITHER the disconnect() callback will set that flag before
anyone tries to submit another request, OR the request will
get in first and then disconnect() will see and unlink it.
Of course, anything using usb_bulk_msg() or usb_control_msg()
(and the many routines that wrap control message calls) isn't
going to be easily unlinkable. (Only the usb-storage driver
pays much attention to that issue...)
I happen to have noticed that it's really easy to avoid using
those two routines ... just submit your own urb (storing it
someplace the disconnect callback can find and cancel it),
and have this almost trivial completion callback:
static void urb_callback (struct urb *urb)
{ complete ((struct completion *)urb->context); }
Of course, the submitter would initialize and wait on that
completion object.
Turns out that if the disconnect() method uses synchronous
unlinks, and the device connects through the shared HCD
framework, there's a guarantee that the completion routine
has returned (your other issue!) before usb_unlink_urb()
does ... unless the urb was already being returned to the
driver. That's because of the way the synchronous wait's
completion is spliced in right after the normal completion.
That guarantee can be used to resolve that 'rmmod' issue
you mentioned, I think. At least for any driver that's
serious about tracking and unlinking all its requests.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
