1. 04 12月, 2012 3 次提交
  2. 28 9月, 2012 2 次提交
  3. 07 8月, 2012 3 次提交
    • G
      Bluetooth: Fix possible deadlock in SCO code · 269c4845
      Gustavo Padovan 提交于
      sco_chan_del() only has conn != NULL when called from sco_conn_del() so
      just move the code from it that deal with conn to sco_conn_del().
      
      [  120.765529]
      [  120.765529] ======================================================
      [  120.766529] [ INFO: possible circular locking dependency detected ]
      [  120.766529] 3.5.0-rc1-10292-g3701f944-dirty #70 Tainted: G        W
      [  120.766529] -------------------------------------------------------
      [  120.766529] kworker/u:3/1497 is trying to acquire lock:
      [  120.766529]  (&(&conn->lock)->rlock#2){+.+...}, at:
      [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170 [bluetooth]
      [  120.766529]
      [  120.766529] but task is already holding lock:
      [  120.766529]  (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at:
      [<ffffffffa00b8401>] sco_conn_del+0x61/0xe0 [bluetooth]
      [  120.766529]
      [  120.766529] which lock already depends on the new lock.
      [  120.766529]
      [  120.766529]
      [  120.766529] the existing dependency chain (in reverse order) is:
      [  120.766529]
      [  120.766529] -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}:
      [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
      [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
      [  120.766529]        [<ffffffffa00b85e9>] sco_connect_cfm+0x79/0x300
      [bluetooth]
      [  120.766529]        [<ffffffffa0094b13>]
      hci_sync_conn_complete_evt.isra.90+0x343/0x400 [bluetooth]
      [  120.766529]        [<ffffffffa009d447>] hci_event_packet+0x317/0xfb0
      [bluetooth]
      [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
      [bluetooth]
      [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
      [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
      [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
      [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
      [  120.766529]
      [  120.766529] -> #0 (&(&conn->lock)->rlock#2){+.+...}:
      [  120.766529]        [<ffffffff81078a8a>] __lock_acquire+0x154a/0x1d30
      [  120.766529]        [<ffffffff8107980e>] lock_acquire+0x8e/0xb0
      [  120.766529]        [<ffffffff813c19e0>] _raw_spin_lock+0x40/0x80
      [  120.766529]        [<ffffffffa00b7ecc>] sco_chan_del+0x4c/0x170
      [bluetooth]
      [  120.766529]        [<ffffffffa00b8414>] sco_conn_del+0x74/0xe0
      [bluetooth]
      [  120.766529]        [<ffffffffa00b88a2>] sco_disconn_cfm+0x32/0x60
      [bluetooth]
      [  120.766529]        [<ffffffffa0093a82>]
      hci_disconn_complete_evt.isra.53+0x242/0x390 [bluetooth]
      [  120.766529]        [<ffffffffa009d747>] hci_event_packet+0x617/0xfb0
      [bluetooth]
      [  120.766529]        [<ffffffffa008aa68>] hci_rx_work+0x2c8/0x890
      [bluetooth]
      [  120.766529]        [<ffffffff81047db7>] process_one_work+0x197/0x460
      [  120.766529]        [<ffffffff810489d6>] worker_thread+0x126/0x2d0
      [  120.766529]        [<ffffffff8104ee4d>] kthread+0x9d/0xb0
      [  120.766529]        [<ffffffff813c4294>] kernel_thread_helper+0x4/0x10
      [  120.766529]
      [  120.766529] other info that might help us debug this:
      [  120.766529]
      [  120.766529]  Possible unsafe locking scenario:
      [  120.766529]
      [  120.766529]        CPU0                    CPU1
      [  120.766529]        ----                    ----
      [  120.766529]   lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
      [  120.766529]
      lock(&(&conn->lock)->rlock#2);
      [  120.766529]
      lock(slock-AF_BLUETOOTH-BTPROTO_SCO);
      [  120.766529]   lock(&(&conn->lock)->rlock#2);
      [  120.766529]
      [  120.766529]  *** DEADLOCK ***
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      269c4845
    • M
      Bluetooth: Added /proc/net/sco via bt_procfs_init() · de9b9212
      Masatake YAMATO 提交于
      Added /proc/net/sco via bt_procfs_init().
      Signed-off-by: NMasatake YAMATO <yamato@redhat.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      de9b9212
    • A
      Bluetooth: Make connect / disconnect cfm functions return void · 9e664631
      Andrei Emeltchenko 提交于
      Return values are never used because callers hci_proto_connect_cfm
      and hci_proto_disconn_cfm return void.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      9e664631
  4. 05 6月, 2012 4 次提交
  5. 09 5月, 2012 7 次提交
  6. 29 3月, 2012 1 次提交
  7. 03 1月, 2012 1 次提交
  8. 23 12月, 2011 1 次提交
  9. 20 12月, 2011 1 次提交
  10. 19 12月, 2011 1 次提交
  11. 19 10月, 2011 1 次提交
  12. 12 8月, 2011 1 次提交
  13. 01 7月, 2011 1 次提交
  14. 11 6月, 2011 1 次提交
  15. 10 6月, 2011 1 次提交
  16. 12 5月, 2011 1 次提交
  17. 19 4月, 2011 1 次提交
  18. 28 2月, 2011 1 次提交
  19. 15 2月, 2011 1 次提交
    • G
      Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko · 64274518
      Gustavo F. Padovan 提交于
      Actually doesn't make sense have these modules built separately.
      The L2CAP layer is needed by almost all Bluetooth protocols and profiles.
      There isn't any real use case without having L2CAP loaded.
      SCO is only essential for Audio transfers, but it is so small that we can
      have it loaded always in bluetooth.ko without problems.
      If you really doesn't want it you can disable SCO in the kernel config.
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      64274518
  20. 14 2月, 2011 1 次提交
  21. 02 12月, 2010 1 次提交
  22. 23 11月, 2010 1 次提交
  23. 18 5月, 2010 1 次提交
  24. 10 5月, 2010 2 次提交
  25. 21 4月, 2010 1 次提交