Messages in this thread | | | Date | Tue, 21 Sep 2010 00:48:25 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [BUG, Regression, bisected] USB mouse causes bug on 1st insert, ignored on 2nd insert, lsusb stuck at usbdev_open |
| |
On Mon, 20 Sep 2010, Alan Stern wrote:
> > Thanks Matt and Phill for confirming the line that triggers the oops. As I > > am not able to reproduce it myself, it's a bit tricky to track down what > > went wrong. > > > > Could you please apply the patch below? It's printing the hid <-> hiddev > > <-> usb_interface connections at various stages of probing and open. > > Hopefully it'll reveal a little bit what goes wrong and where. > > Jiri: > > There's something very fishy going on here. Even more so than these > bug reports suggest. > > The whole business about hiddev_driver in hiddev.c looks bogus. It > doesn't get used for anything and it never binds to an interface. > Which means that the usb_find_interface call in hiddev_open should > never succeed. At the very least it would need to specify hid_driver > instead of hiddev_driver.
Yeah. That has been introduced by Arnd while removing BKL, and was bogus. It has been fixed by 8fe294caf8c868edd9046251824a0af91991bf43 ("HID: fix hiddev's use of usb_find_interface"), which makes it use hid_driver (hopefully) correctly.
But since that commit, we are getting NULL pointer dereferences on intfdata->hiddev in hiddev_open(). Very likely, it's not fault of that commit -- after Arnd's bd25f4dd6972755579d0ea50d1a5ace2e9b00d1a and before Guillaume's 8fe294caf8c868edd9046251824a0af91991bf43 we were not hitting that codepath at all in fact.
> I have no idea what's really happening. Can you figure it out?
I am trying, but on my testing systems everything is behaving correctly, so it's a bit more difficult. Ideas welcome.
Thanks,
-- Jiri Kosina SUSE Labs, Novell Inc.
| |