> >>> Driver decides to follow Dave's > >>> advice and leak memory in this error situation, so it doesn't > >>> free its structures, and exits the disconnect method. > > The first part of the advice was equally important: log a message, > so that eventually, in the unlikely case something bad happens, it > can be tracked down with less pain. > > All we know is that by the statistics, it's likely that leaking is > going to avoid _immediate_ problems. So there's no better option > for such situations. Except maybe adding a short delay if you're > deeply concerned about letting module unload proceed right then.
Hi Dave, I'm still confused about how leaking memory can help. The problem from the beginning was: making sure all urbs have completed in the disconnect handler (though perhaps I didn't make it clear that I was talking about the disconnect routine). Suppose usb_unlink_urb fails for some urb and you decide not to free memory (and print a message - I have nothing against that!). You then return from the disconnect handler with an urb in flight. This is fatal, in part because the module could be unloaded, but I guess also because the USB subsystem will have freed all kinds of data structures associated with that USB device. In any case, if the completion handler fires one day most likely you are dead. Conclusion A: you must be sure to have unlinked all urbs before leaving the disconnect routine. Conclusion B: you must loop around retrying usb_unlink_urb until it succeeds (if ever). Is that right? All the best, Duncan. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
