diff options
| author | Gustavo Padovan | 2012-11-21 02:25:54 +0100 |
|---|---|---|
| committer | Gustavo Padovan | 2012-12-03 18:59:10 +0100 |
| commit | dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 (patch) | |
| tree | d4319c396be9da260ea363105b76d2548696bd8f /net/bluetooth/hci_core.c | |
| parent | Bluetooth: Remove OOB data if device was discovered in band (diff) | |
| download | kernel-qcow2-linux-dc2a0e20fbc85a71c63aa4330b496fda33f6bf80.tar.gz kernel-qcow2-linux-dc2a0e20fbc85a71c63aa4330b496fda33f6bf80.tar.xz kernel-qcow2-linux-dc2a0e20fbc85a71c63aa4330b496fda33f6bf80.zip | |
Bluetooth: Add missing lock nesting notation
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
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Diffstat (limited to 'net/bluetooth/hci_core.c')
0 files changed, 0 insertions, 0 deletions