On Thu, 20 Feb 2003, Greg KH wrote:
> On Thu, Feb 20, 2003 at 02:46:51AM +0100, Oliver Neukum wrote:
> > > What? If a driver is undergoing unload, then any kind of return from
> > > usb_submit_urb() (error or not) will cause an oops.
> >
> > Exactly. You are checking for an error that you can't handle.
> > What would usb_submit_urb() do if increasing the usage count
> > fails?
>
> Return an error. But remember, we aren't trying to protect the call to
> usb_submit_urb() at that point in time, it better already be protected
> (Like Duncan pointed out). We're trying to protect the module later,
> when the close() call has decremented the module count, yet urbs are
> still in flight through the usb core (due to the driver not knowing
> about them anymore, like in the visor driver.)
>
> That's why we need this reference count.
Nope, that's why doing this is harmful and puts policy even into usbcore.
This issue affects only drivers that have active URBs although they are
not logically opened. In other cases the usage count is elevated anyway.
Going this route while avoiding races with unloading requires the drivers
to have mutual exclusion with module_exit anyway. They can just as well
increment their usage count then as well sparing all others the overhead.
But putting this into usbcore means that a driver that has active urbs
in the closed state _cannot_ implement the ability to be unloaded in
the closed state reliably. Such drivers are forced to live in a maybe
unloadable state.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
