On Tue, 2 Sep 2014, Benjamin Tissoires wrote: > > Whenever either disconnecting the USB device or simply rmmod'ing the module > > (even when not in use), I get a kernel panic. I haven't managed to capture a > > backtrace, but at least the first two lines were saved after an rmmod: > > > > 18:53:17 kernel: thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0 > > <snip, rmmod hid-thingm:> > > 08:38:42 kernel: BUG: unable to handle kernel paging request at fffffffb8a80aaf8 > > 08:38:42 kernel: IP: [<ffffffff8106e30c>] osq_lock+0x3c/0x110 Hmm, so the only lock that is taken in thingm driver itself is rgb->tdev->lock, which is thingm_device->lock, properly initialized in _probe(). So my first thought was that the work is not cancelled properly, causing use-after-free on the lock with the workqueue firing at the time the drvier has cleaned up everything, but that doesn't seem to be the case, as thingm_remove() -> thingm_remove_rgb() seems to be doing the right thing. Dylan, is there any chance for you to capture more complete backtrace from the oops? serial console, netconsole, anything? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
