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.
> 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.
--
Peter Osterlund - [EMAIL PROTECTED]
http://w1.894.telia.com/~u89404340
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
