1. 04 12月, 2012 4 次提交
    • F
      Bluetooth: Implement deferred sco socket setup · 20714bfe
      Frédéric Dalleau 提交于
      In order to authenticate and configure an incoming SCO connection, the
      BT_DEFER_SETUP option was added. This option is intended to defer reply
      to Connect Request on SCO sockets.
      When a connection is requested, the listening socket is unblocked but
      the effective connection setup happens only on first recv. Any send
      between accept and recv fails with -ENOTCONN.
      Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      20714bfe
    • F
      Bluetooth: Add BT_DEFER_SETUP option to sco socket · b96e9c67
      Frédéric Dalleau 提交于
      This option will set the BT_SK_DEFER_SETUP bit in socket flags.
      Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      b96e9c67
    • G
      Bluetooth: cancel power_on work when unregistering the device · b9b5ef18
      Gustavo Padovan 提交于
      We need to cancel the hci_power_on work in order to avoid it run when we
      try to free the hdev.
      
      [ 1434.201149] ------------[ cut here ]------------
      [ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
      [ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci
      _power_on+0x0/0x90
      [ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G        W    3.7.0-rc5-next-
      20121112-sasha-00018-g2f4ce0e #127
      [ 1434.210760] Call Trace:
      [ 1434.210760]  [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
      [ 1434.210760]  [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
      [ 1434.210760]  [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
      [ 1434.210760]  [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
      [ 1434.210760]  [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
      [ 1434.210760]  [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
      [ 1434.210760]  [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
      [ 1434.210760]  [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
      [ 1434.210760]  [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
      [ 1434.210760]  [<ffffffff8125eee7>] kfree+0x227/0x330
      [ 1434.210760]  [<ffffffff83785db0>] bt_host_release+0x10/0x20
      [ 1434.210760]  [<ffffffff81e539e5>] device_release+0x65/0xc0
      [ 1434.210760]  [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
      [ 1434.210760]  [<ffffffff819d39cd>] kobject_release+0xd/0x10
      [ 1434.210760]  [<ffffffff819d33cc>] kobject_put+0x4c/0x60
      [ 1434.210760]  [<ffffffff81e548b2>] put_device+0x12/0x20
      [ 1434.210760]  [<ffffffff8376a334>] hci_free_dev+0x24/0x30
      [ 1434.210760]  [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
      [ 1434.210760]  [<ffffffff8127be12>] __fput+0x122/0x250
      [ 1434.210760]  [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
      [ 1434.210760]  [<ffffffff8127bf49>] ____fput+0x9/0x10
      [ 1434.210760]  [<ffffffff81133402>] task_work_run+0xb2/0xf0
      [ 1434.210760]  [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
      [ 1434.210760]  [<ffffffff83bfb0ea>] int_signal+0x12/0x17
      [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---
      
      Cc: stable@vger.kernel.org
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      b9b5ef18
    • 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 7 次提交
  4. 19 11月, 2012 3 次提交
  5. 17 11月, 2012 21 次提交