On Sunday 20 January 2002 00:07, David Brownell wrote:
> I have the strong feeling that the "Subject: " line for this
> series of posts should change:
>
> Aunt Tillie Writes a USB Device Driver :)
No, please don't. Cthulhu help us !
But writing a driver should be as simple as possible.
Actually writing one is simple. Unfortunately writing a driver
without races is hard.
> Specifically which drivers do you think have this problem?
>
> I think I see variants of it in ov511, pwc, and se401. That's
> just looking at some of the few drivers that do their own
> module refcounts; network and char devices shouldn't do
> that, but they could have analagous bugs.
Exactly, in principle disconnect() may eventually lead to decreasing
the module usage count in all drivers. It just takes more time,
which decreases the likelihood of harm being done.
> The basic issue seems to be something we've known for
> a while: not all drivers handle disconnect() correctly. They
> need to get rid of all pending requests, with no exceptions
> made for requests (or completions, which seems to be the
> issue you're highlighting here) that are "in flight". If they do
> that correctly, then when the module_exit() code returns
> it'll always be safe to unload.
The problem is that there's a way to get rid of a request, but
no way to get rid of a completion, at least with respect to unload.
With respect to data structures the completion handler touches
it's a standard technique. That's not true for the code itself.
> I recall thinking about related issues with "usbnet". There,
> the disconnect() processing uses async unlinks, and blocks
> until it's explicitly woken up by the completion code after all
> the pending urbs are unlinked and freed.
>
> No "wait_for_completion_handler()" API is needed, since
> the <linux/completion.h> and the a correct completion handler
> will do the job quite naturally.
No completion handler can do the job without a small window.
linux/completion.h guards against a data structure going
away. They are useless with regard to code being freed.
The code has to look like or can be understood in terms of:
wake_up(&waiters_on_completion);
/* here's the window */
return;
Admittedly it's a small window, but an extremely badly timed DMA could do
harm. Using completion handlers just makes matters worse, because they
are complexer and take more time to execute.
Or in other words, if the guard is against unloading the completion handler,
which is a part of the driver, the code to do it cannot be in the completion
handler.
It has to be in another module or must be under the big kernel lock.
> p.s. Surely you mean usb_free_urb(u), not kfree(u) ...
Actually, I was refering to a data structure, which the urb is part of.
But it doesn't matter in this example.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
