On Fri, Jan 04, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > >>EIP; c012ad65 <kfree+35/a0> <===== > > Trace; c4817ee4 <[usbcore]usb_destroy_configuration+104/210> > > Trace; c48171e2 <[usbcore]usb_free_dev+22/50> > > Trace; c48288b5 <[usb-uhci]process_urb+1e5/200> > > Trace; c4828991 <[usb-uhci]uhci_interrupt+c1/130> > > > > As can be seen from the above, usb_destroy_configuration is called > > from interrupt context, and I don't see how a kernel thread could > > serialize interrupt processing, unless it is preventing the interrupts > > from triggering. > > ... > > Maybe the dec_and_test is not supposed to ever return true when called > > from interrupt context. > > Exactly.
Just to clarify, dec_and_test can return true when called from an interrupt context. The dec_and_test implementation doesn't care what context it is. The USB core code for usb_free_dev path is all interrupt safe (just some kree's) and the HCD's deallocate() routine should all be interrupt safe too. In almost every case, usb_free_dev will be called in the khubd context. The only case I can think of where it would be called from an interrupt context (in the bug free case) would be a device disconnecting and the driver doing an asynchronous unlink (like for the uhci drivers). Then the reference would then hit 0 in the interrupt context. > > That would indicate there is a reference > > counting bug somewhere. > > Yes, such bugs do crop up from time to time. OHCI reports > calls to the "free device" routine in_interrupt() as errors, it > might be helpful if the UHCIs did the same thing. sohci_free_dev doesn't need to be so complex. I used to have code similar to that in uhci.c, but then realized it's not necessary since in a normal working setup, it can never be called when there are still URB's around. When an URB is submitted, the HCD should increment the reference count. When it's completely done with the URB, it should decrement the device's reference count. Since the reference count is always > 0 when an URB is owned by the HCD, then the HCD's deallocate() will never get called when it owns an URB and thusly, it doesn't need to cleanup any TD's, etc since it will be done in the normal code path. It does look like usb-ohci.c allocates some state per device on device connect and disconnect, so that code may need to remain, but all of the functions it calls should be interrupt safe (pci_pool_free, etc) JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
