Re: lockdep report at resume

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

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

> > [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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]