> > > 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. > > It could be included into usb_unlink_urb() which is called under BKL > from disconnect().
>From khubd disconnect() paths, maybe, but not the others. And of course, what happens when BKL finally vanishes? :) Plus, that wouldn't protect completions in other situations. > > 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. > > Sorry, no. > This would break horribly for drivers which use the method of providing > a function pointer to the module subsystem to check for unloadability. I can't follow this. The module system's core mechanism to test "is it unloadable" gets bypassed, yet you'd expect that somehow to work? While respecting that mechanism would not work??? - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
