On Mon, May 13, 2002, Greg KH <[EMAIL PROTECTED]> wrote: > On Mon, May 13, 2002 at 03:29:37AM -0700, David Brownell wrote: > > Naturally I don't like this patch, and I may comment more > > on it a bit later when I'm not just up late and sleepless ... :) > > > > > > But I'll correct a few misstatements right now about the > > current 2.5 behavior. (And for what it's worth, only "uhci.c" > > has any problems with that -- from what I've seen.) > > > > > - It made the USB code more complicated as a whole with the introduction > > > of an additional cleanup path for devices. > > > > Not so. It has detected/reported failures to correctly support > > the _original_ cleanup paths, though. For example, device > > drivers that hang on to references after their disconnect() > > methods complete. (Which can make "rmmod" break, for > > example completion callbacks going to where the module > > used to be loaded.) > > Hm, we should probably fix that. We should test for that in the usb > core before passing the call down to the host controller driver.
That's a device driver bug. If it's still hanging onto references and the module is removed, it's a bug. That has nothing to do with the core, or HCD's. Take a look at what uhci.c does to clean up in that situation. > > And it's guaranteed that the *hci_free_dev() code is called in > > a thread context, per the original API guarantees. And also > > matching the behavior of every other Linux device driver > > framework I've had a chance to look at. > > So should we add a BUG() call if_interrupt() is true when we go to > clean up the finally usb_free_dev() call to catch for this? NO, NO, NO. usb_free_dev() is called when the last reference is decremented, which can be in ANY context! But it doesn't matter since usb_free_dev doesn't do any blocking. > > One thing to keep in mind is that to the extent that many > > device drivers _today_ are working "correctly", they're not > > going to trigger such bugs. However, Johannes' change > > makes the kernel more fragile in the face of newer drivers > > which do have bugs in such areas. > > If we add the BUG() mentioned above, how are things more fragile? > Personally, they look more stable to me. Just code the drivers correctly. The kernel is not the place to coddle coders who cannot code correctly. It's a dangerous place and it'll remain so for a long time. Just like how the kernel doesn't protect root from shooting himself in the foot, the kernel doesn't protect any other kernel code from doing the wrong thing either. It's root's responsibility to the do the right thing as it's the coders responsibility to do the right thing. JE _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
