> No completion handler can do the job without a small window. > ... > wake_up(&waiters_on_completion); > /* here's the window */ > return;
That is, at least the "return" instruction is at risk ... yeech! > 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. I'd been more thinking about having the disconnect() not race against the completion handler, but I do see this other point. BKL is not a realistic option here. Which would leave this as some usbcore role, except that it doesn't explicitly know which module makes each request. One possible solution: submit urbs to a "struct usb_interface *" (and endpoint), and update that structure so that it's bound to current device configurations. We already believe that it needs mem_flags ... the old API could be a wrapper around this new/preferred API. Then the "hcd.c" layer could do something like call __MOD_INC_USE_COUNT(intf->driver->owner) when an URB is submitted (a handful of instructions), __MOD_DEC_USE_COUNT(owner) when the completion function returns. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
