On Sat, Jan 05, 2002, Peter Osterlund <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt <[EMAIL PROTECTED]> writes:
>
> > While the patch is good for the header->bLength case, I don't think
> > this is what is causing the problem.
> >
> > All connects and disconnects are serialized through khubd. There's no
> > way we could call usb_destroy_configuration when we're in
> > usb_parse_interface.
>
> Here is part of the stack trace from the oops/panic in my first
> message about this problem:
>
> >>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.
>
> Anyway, usb_free_dev looks like this:
>
> void usb_free_dev(struct usb_device *dev)
> {
> if (atomic_dec_and_test(&dev->refcnt)) {
> dev->bus->op->deallocate(dev);
> usb_destroy_configuration(dev);
> ...
>
> Maybe the dec_and_test is not supposed to ever return true when called
> from interrupt context. That would indicate there is a reference
> counting bug somewhere.
Yes, this definately looks like a reference counting bug.
This is strange since usb_alloc_dev initially sets the count to 1. The
only place the core decrements the usage is in usb_disconnect, which is
synchronous to usb_parse_interface.
usb-uhci.c looks good as far as reference counting. The core looks
clean. The hub driver looks clean. Atleast in 2.4.13. I should check
2.5.2-pre6.
It couldn't have gotten to a driver since the descriptor parsing wasn't
done yet. Hmmm.
> > Also, if header->bLength is < 2, then we'll almost always get an oops,
> > not just if the device disappears quickly.
>
> That's another strange thing. I added code to explicitly set bLength
> to 0, just to trigger this error condition. Then I added debug
> messages in usb_destroy_configuration to see what would happen, and
> the kfree(as->extra) line was never executed. It didn't even
> kfree(ifp->altsetting), so this looks like a memory leak.
Did you add the debugging before or after your patch (or Greg's patch)?
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
