On Tue, 9 Sep 2014, Joe Lawrence wrote: ...
> hub_events does later go on to check for hub->disconnected, but that's > outside the hub_event_lock and *after* the call to usb_lock_device. In > my traces, that's too late as its already been freed and poisoned. > > There's probably a better way to coordinate these two functions, but the > following change (on top of the one in my other mail) has run our device > removal tests without incident thus far. The analysis is correct. > Thanks, > > -- Joe > > -->8-- -->8-- > > From e5b3b8c6ffd282312dc8c9bec0ce261f56ae9731 Mon Sep 17 00:00:00 2001 > From: Joe Lawrence <joe.lawre...@stratus.com> > Date: Tue, 9 Sep 2014 09:39:38 -0400 > Subject: [PATCH] usb: hub: take hub->hdev reference when adding to eventlist > > During surprise device hotplug removal tests, it was observed that > hub_events may try to call usb_lock_device on a device that has already > been freed. Protect the usb_device by taking out a reference before the > hub is added to the eventlist, releasing the reference after hub_events > is finished using it. The fix is almost correct. Take the reference when hub_events removes the hub from hub_event_list, while the hub_event_lock is still held. That way the get and put occur in the same subroutine, and there's opportunity for them to become unbalanced. Also, for the sake of good form, do the put calls in the opposite order of the get calls. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
