> > It "should" only shake out code that doesn't play by today's rules, > > right? Or am I missing something? > > Yes. It shook out the fact that uhci.c wasn't updated to play by the new > rules.
No, a code inspection shook out the fact that it didn't even play by the 2.4 rules, which require HCDs to clean up their device state when bus->op->deallocate() is called. It's a latent problem, not yet seen in the wild, masked by the same loose coding in 2.4 that masks other driver cleanup bugs. Note that Andries' BUG() is (a) different from the one I noticed uhci.c might trigger, and is even in a different source file; also (b) followed several other USB problems, one of which is IMO likely causing his BUG(). > However, it can only be useful if code uses reference counting after > uhci_disconnect is called, which is a perfectly legitimate use of > reference counting in the kernel. That is what it is traditionally > used for, so the memory doesn't disappear under us. But there _is_ no uhci_disconnect()!! Do you mean uhci_free_dev()? The NOP? Remember that method must be called when it can sleep, and the loose 2.4 way of managing device refcounts couldn't guarantee that. (Caused oopsing in the correct code, not the buggy code...) If you try to make refcounting be "poor man's kernel garbage collection", you'll either need to provide another way to ensure it's never called in_interrupt(), or else be making incompatible changes to at least bus->op->deallocate(). I'm sure UHCI doesn't care whether its NOP can sleep or not, but it'd seem wrong to change semantics of bus->op->deallocate() so that (unlike other hotplug "device is gone" calls) it may not sleep. And I'd rather not change the HCDs that rely on that, either. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
