On Mon, 17 Sep 2012, Don Zickus wrote: > I have added some in-depth analysis from our customer. > > > The problem is that the failing routine was called with a pointer to usbdev in > memory that has already been freed and overwritten with the pool poison > pattern. > This causes an access violation on line 502:
The stack trace shows that the failure occurred in usb_device_dump(), which was called from usb_device_read(). Since it wasn't a recursive call, the usbdev argument must have pointed to the root-hub device. I don't see how this could have happened if the kernel included the patch I sent earlier. usb_device_read() holds the usb_bus_list_lock mutex throughout, and it tests that the root hub's devnum field is not equal to 0 before calling usb_dump_device(). Meanwhile, usb_remove_hcd() sets hcd->self.bus.root_hub->devnum to 0 while holding usb_bus_list_lock, and it doesn't deallocate the root hub device until after the mutex is dropped. Are you certain that the test was conducted with the patch in place? If you want to track down what's going wrong, you'll have to add some debugging code to usb_device_read() and usb_remove_hcd(). By the time usb_device_dump() starts running, it's already too late. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
