1. 03 Dec, 2012 1 commit
    • Gustavo Padovan's avatar
      Bluetooth: Add missing lock nesting notation · dc2a0e20
      Gustavo Padovan authored
      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-gc1d5dc4a #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: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      dc2a0e20
  2. 20 Nov, 2012 5 commits
  3. 19 Nov, 2012 10 commits
  4. 16 Nov, 2012 24 commits