On Wed, 2009-02-11 at 13:03 +0100, Jiri Kosina wrote:

quoted

[20920.459736] events/0/9 is trying to acquire lock:
[20920.459951]  (&dev->mutex){--..}, at: [<ffffffff804be0ac>] input_disconnect_device+0x2c/0xf0
[20920.460369] 
[20920.460370] but task is already holding lock:
[20920.460637]  (&usbhid->reset_work){--..}, at: [<ffffffff8025a933>] run_workqueue+0xb3/0x250
[20920.461049] 
[20920.461050] which lock already depends on the new lock.
[20920.461051] 
[20920.461425] 
[20920.461425] the existing dependency chain (in reverse order) is:
[20920.461767] 
[20920.461767] -> #4 (&usbhid->reset_work){--..}:
[20920.464572] 
[20920.464572] -> #3 (events){--..}:
[20920.468134] 
[20920.468134] -> #2 (cpu_add_remove_lock){--..}:
[20920.468134] 
[20920.468134] -> #1 (polldev_mutex){--..}:
[20920.468134] 
[20920.468134] -> #0 (&dev->mutex){--..}:

OK, so we are calling usb_reset_device() from hid_reset() workqueue. You 
have a composite device, mouse interface being handled by bcm5974 driver, 
and keyboard interface being handled by usbhid driver.

Right.

bcm5974 driver doesn't have _pre_reset() and _post_reset() callbacks, so 
full unbind/bind cycle is performed by USB core. bcm5974_disconnect() 
calls input_unregister_device(), which creates reset_work -> 
input_dev->mutex dependency.

Yup

Unfortunately I don't seem to see from the lockdep dumps where does the 
input_dev->mutex -> reset_work dependency come from, am I just completely 
blind?

Well, there's the entire chain of dependencies, so it's via polldev, and
polldev depends on cpu_add_remove_lock, etc. So it's across a whole lot
of different subsystems... the dependency is quite complex here! There's
probably no direct dependency of input_dev->mutex -> reset_work, but
reset_work is on the global workqueue ("events") which has the
dependency via some _other_ work that some _other_ subsystem is also
giving to schedule_work()!

I will look into this.

Thanks.

johannes