1. 10 1月, 2013 1 次提交
    • G
      Bluetooth: Check if the hci connection exists in SCO shutdown · b7e98b51
      Gustavo Padovan 提交于
      Checking only for sco_conn seems to not be enough and lead to NULL
      dereferences in the code, check for hcon instead.
      
      <1>[11340.226404] BUG: unable to handle kernel NULL pointer dereference at
      0000000
      8
      <4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0
      <4>[11340.226629] EAX: f063a740 EBX: 00000000 ECX: f58f4544 EDX: 00000000
      <4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f EBP: e0fdff38 ESP: e0fdff1c
      <0>[11340.226674] Stack:
      <4>[11340.226682]  c184db87 c1251028 dec83e00 e0fdff38 c1754aef dec83e00
      00000000
      e0fdff5c
      <4>[11340.226718]  c184f587 e0fdff64 e0fdff68 5f9a081f e0fdff5c c1751852
      d7813800
      62262f10
      <4>[11340.226752]  e0fdff70 c1753c00 00000000 00000001 0000000d e0fdffac
      c175425c
      00000041
      <0>[11340.226793] Call Trace:
      <4>[11340.226813]  [<c184db87>] ? sco_sock_clear_timer+0x27/0x60
      <4>[11340.226831]  [<c1251028>] ? local_bh_enable+0x68/0xd0
      <4>[11340.226846]  [<c1754aef>] ? lock_sock_nested+0x4f/0x60
      <4>[11340.226862]  [<c184f587>] sco_sock_shutdown+0x67/0xb0
      <4>[11340.226879]  [<c1751852>] ? sockfd_lookup_light+0x22/0x80
      <4>[11340.226897]  [<c1753c00>] sys_shutdown+0x30/0x60
      <4>[11340.226912]  [<c175425c>] sys_socketcall+0x1dc/0x2a0
      <4>[11340.226929]  [<c149ba78>] ? trace_hardirqs_on_thunk+0xc/0x10
      <4>[11340.226944]  [<c18860f1>] syscall_call+0x7/0xb
      <4>[11340.226960]  [<c1880000>] ? restore_cur+0x5e/0xd7
      <0>[11340.226969] Code: <f0> ff 4b 08 0f 94 c0 84 c0 74 20 80 7b 19 01 74
      2f b8 0a 00 00
      Reported-by: NChuansheng Liu <chuansheng.liu@intel.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      b7e98b51
  2. 04 12月, 2012 3 次提交
  3. 28 9月, 2012 2 次提交
  4. 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
  5. 05 6月, 2012 4 次提交
  6. 09 5月, 2012 7 次提交
  7. 29 3月, 2012 1 次提交
  8. 03 1月, 2012 1 次提交
  9. 23 12月, 2011 1 次提交
  10. 20 12月, 2011 1 次提交
  11. 19 12月, 2011 1 次提交
  12. 19 10月, 2011 1 次提交
  13. 12 8月, 2011 1 次提交
  14. 01 7月, 2011 1 次提交
  15. 11 6月, 2011 1 次提交
  16. 10 6月, 2011 1 次提交
  17. 12 5月, 2011 1 次提交
  18. 19 4月, 2011 1 次提交
  19. 28 2月, 2011 1 次提交
  20. 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
  21. 14 2月, 2011 1 次提交
  22. 02 12月, 2010 1 次提交
  23. 23 11月, 2010 1 次提交
  24. 18 5月, 2010 1 次提交
  25. 10 5月, 2010 2 次提交