1. 04 12月, 2012 1 次提交
    • G
      Bluetooth: Add missing lock nesting notation · dc2a0e20
      Gustavo Padovan 提交于
      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: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      dc2a0e20
  2. 21 11月, 2012 5 次提交
  3. 20 11月, 2012 5 次提交
  4. 19 11月, 2012 3 次提交
  5. 02 11月, 2012 26 次提交