Gustavo Padovan
37021f68aa
Bluetooth: Add missing lock nesting notation
commit dc2a0e20fb upstream.
This patch fixes the following report, it happens when accepting rfcomm
connections:
[ 228.165378] =============================================
[ 228.165378] [ INFO: possible recursive locking detected ]
[ 228.165378] 3.7.0-rc1-00536-gc1d5dc4 #120 Tainted: G W
[ 228.165378] ---------------------------------------------
[ 228.165378] bluetoothd/1341 is trying to acquire lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
[ 228.165378]
[ 228.165378] but task is already holding lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
[ 228.165378]
[ 228.165378] other info that might help us debug this:
[ 228.165378] Possible unsafe locking scenario:
[ 228.165378]
[ 228.165378] CPU0
[ 228.165378] ----
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378]
[ 228.165378] *** DEADLOCK ***
[ 228.165378]
[ 228.165378] May be due to missing lock nesting notation
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-01-03 03:33:27 +00:00
..
2011-11-21 14:29:25 -02:00
2011-11-21 14:28:45 -02:00
2011-09-27 18:15:55 -03:00
2013-01-03 03:33:27 +00:00
2011-09-27 18:16:07 -03:00
2012-11-16 16:46:46 +00:00
2012-04-22 15:31:12 -07:00
2012-09-12 03:36:51 +01:00
2012-09-19 15:04:51 +01:00
2011-10-31 19:30:28 -04:00
2012-10-10 03:31:11 +01:00
2012-10-10 03:31:11 +01:00
2011-11-07 10:55:33 -08:00
2011-10-18 23:36:43 -04:00
2012-10-30 23:26:43 +00:00