On Wed, 14 Mar 2012, Dave Jones wrote:
> One of our users hit this recently..
>
>
> :[ INFO: possible recursive locking detected ]
> :3.3.0-0.rc5.git3.1.fc17.x86_64 #1 Tainted: G W
> :---------------------------------------------
> :usb-storage/14846 is trying to acquire lock:
> : (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
> :but task is already holding lock:
> : (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
> :other info that might help us debug this:
> : Possible unsafe locking scenario:
> : CPU0
> : ----
> : lock(&(us->dev_mutex));
> : lock(&(us->dev_mutex));
> : *** DEADLOCK ***
> : May be due to missing lock nesting notation
> :2 locks held by usb-storage/14846:
> : #0: (&__lockdep_no_validate__){......}, at: [<ffffffff8147e6a5>] usb_lock_device_for_reset+0x95/0x100
> : #1: (&(us->dev_mutex)){+.+.+.}, at: [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
> :stack backtrace:
> :Pid: 14846, comm: usb-storage Tainted: G W 3.3.0-0.rc5.git3.1.fc17.x86_64 #1
> :Call Trace:
> : [<ffffffff810cbdaf>] __lock_acquire+0x168f/0x1bb0
> : [<ffffffff81021083>] ? native_sched_clock+0x13/0x80
> : [<ffffffff810210f9>] ? sched_clock+0x9/0x10
> : [<ffffffff810210f9>] ? sched_clock+0x9/0x10
> : [<ffffffff810a2975>] ? sched_clock_local+0x25/0xa0
> : [<ffffffff810cc9a1>] lock_acquire+0xa1/0x1e0
> : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
> : [<ffffffff81699c86>] mutex_lock_nested+0x76/0x3a0
> : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
> : [<ffffffffa0481c0c>] ? usb_stor_pre_reset+0x1c/0x20 [usb_storage]
> : [<ffffffffa0481c0c>] usb_stor_pre_reset+0x1c/0x20 [usb_storage]
> : [<ffffffff8148184d>] usb_reset_device+0x7d/0x190
> : [<ffffffffa048119c>] usb_stor_port_reset+0x7c/0x80 [usb_storage]
> : [<ffffffffa0481234>] usb_stor_invoke_transport+0x94/0x560 [usb_storage]
> : [<ffffffff810cd3b2>] ? mark_held_locks+0xb2/0x130
> : [<ffffffff8169dbd0>] ? _raw_spin_unlock_irq+0x30/0x50
> : [<ffffffffa047fe3e>] usb_stor_transparent_scsi_command+0xe/0x10 [usb_storage]
> : [<ffffffffa0481ae3>] usb_stor_control_thread+0x173/0x280 [usb_storage]
> : [<ffffffffa0481970>] ? fill_inquiry_response+0x20/0x20 [usb_storage]
> : [<ffffffff8108a3f7>] kthread+0xb7/0xc0
> : [<ffffffff816a7d34>] kernel_thread_helper+0x4/0x10
> : [<ffffffff8169e0f4>] ? retint_restore_args+0x13/0x13
> : [<ffffffff8108a340>] ? kthread_worker_fn+0x1a0/0x1a0
> : [<ffffffff816a7d30>] ? gs_change+0x13/0x13
Is there any way to reproduce this?
It seems to be saying that usb_stor_pre_reset() was called twice
without usb_stor_post_reset() being called in between, because the
post_reset routine is where the lock gets released. I don't know of
any way that could happen.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
