1. 19 Jul, 2011 1 commit
  2. 18 Jul, 2011 1 commit
  3. 15 Jul, 2011 6 commits
  4. 13 Jul, 2011 2 commits
  5. 11 Jul, 2011 2 commits
  6. 10 Jul, 2011 1 commit
  7. 08 Jul, 2011 20 commits
  8. 07 Jul, 2011 7 commits
    • Mat Martineau's avatar
      Bluetooth: Remove L2CAP busy queue · fadd192e
      Mat Martineau authored
      The ERTM receive buffer is now handled in a way that does not require
      the busy queue and the associated polling code.
      Signed-off-by: default avatarMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      fadd192e
    • Mat Martineau's avatar
      Bluetooth: Use event-driven approach for handling ERTM receive buffer · e328140f
      Mat Martineau authored
      This change moves most L2CAP ERTM receive buffer handling out of the
      L2CAP core and in to the socket code.  It's up to the higher layer
      (the socket code, in this case) to tell the core when its buffer is
      full or has space available.  The recv op should always accept
      incoming ERTM data or else the connection will go down.
      
      Within the socket layer, an skb that does not fit in the socket
      receive buffer will be temporarily stored.  When the socket is read
      from, that skb will be placed in the receive buffer if possible.  Once
      adequate buffer space becomes available, the L2CAP core is informed
      and the ERTM local busy state is cleared.
      
      Receive buffer management for non-ERTM modes is unchanged.
      Signed-off-by: default avatarMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      e328140f
    • Mat Martineau's avatar
      Bluetooth: Move code for ERTM local busy state to separate functions · 26f880d2
      Mat Martineau authored
      The local busy state is entered and exited based on buffer status in
      the socket layer (or other upper layer).  This change is in
      preparation for general buffer status reports from the socket layer,
      which will then be used to change the local busy status.
      Signed-off-by: default avatarMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      26f880d2
    • Andre Guedes's avatar
      Bluetooth: Fix potential deadlock in mgmt · 8c156c32
      Andre Guedes authored
      All threads running in process context should disable local bottom
      halve before locking hdev->lock.
      
      This patch fix the following message generated when Bluetooh module
      is loaded with enable_mgmt=y (CONFIG_PROVE_LOCKING enabled).
      
      [  107.880781] =================================
      [  107.881631] [ INFO: inconsistent lock state ]
      [  107.881631] 2.6.39+ #1
      [  107.881631] ---------------------------------
      [  107.881631] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [  107.881631] rcuc0/7 [HC0[0]:SC1[3]:HE1:SE0] takes:
      [  107.881631]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
      [  107.881631] {SOFTIRQ-ON-W} state was registered at:
      [  107.881631]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
      [  107.881631]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  107.881631]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
      [  107.881631]   [<ffffffffa0011cc2>] mgmt_control+0xd4d/0x175b [bluetooth]
      [  107.881631]   [<ffffffffa0013275>] hci_sock_sendmsg+0x97/0x293 [bluetooth]
      [  107.881631]   [<ffffffff8121940c>] sock_aio_write+0x126/0x13a
      [  107.881631]   [<ffffffff810a35fa>] do_sync_write+0xba/0xfa
      [  107.881631]   [<ffffffff810a3beb>] vfs_write+0xaa/0xca
      [  107.881631]   [<ffffffff810a3d80>] sys_write+0x45/0x69
      [  107.881631]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
      [  107.881631] irq event stamp: 2100876
      [  107.881631] hardirqs last  enabled at (2100876): [<ffffffff812b40d4>] restore_args+0x0/0x30
      [  107.881631] hardirqs last disabled at (2100875): [<ffffffff812b3f6a>] save_args+0x6a/0x70
      [  107.881631] softirqs last  enabled at (2100862): [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
      [  107.881631] softirqs last disabled at (2100863): [<ffffffff812b56bc>] call_softirq+0x1c/0x26
      [  107.881631]
      [  107.881631] other info that might help us debug this:
      [  107.881631]  Possible unsafe locking scenario:
      [  107.881631]
      [  107.881631]        CPU0
      [  107.881631]        ----
      [  107.881631]   lock(&(&hdev->lock)->rlock);
      [  107.881631]   <Interrupt>
      [  107.881631]     lock(&(&hdev->lock)->rlock);
      [  107.881631]
      [  107.881631]  *** DEADLOCK ***
      [  107.881631]
      [  107.881631] 1 lock held by rcuc0/7:
      [  107.881631]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
      [  107.881631]
      [  107.881631] stack backtrace:
      [  107.881631] Pid: 7, comm: rcuc0 Not tainted 2.6.39+ #1
      [  107.881631] Call Trace:
      [  107.881631]  <IRQ>  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
      [  107.881631]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
      [  107.881631]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
      [  107.881631]  [<ffffffff810504bb>] mark_lock+0x106/0x258
      [  107.881631]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
      [  107.881631]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
      [  107.881631]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
      [  107.881631]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
      [  107.881631]  [<ffffffff812b3952>] _raw_spin_lock_bh+0x31/0x40
      [  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
      [  107.881631]  [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
      [  107.881631]  [<ffffffffa000d3fe>] hci_event_packet+0x122b/0x3e12 [bluetooth]
      [  107.881631]  [<ffffffff81050658>] ? mark_held_locks+0x4b/0x6d
      [  107.881631]  [<ffffffff812b3cff>] ? _raw_spin_unlock_irqrestore+0x40/0x4d
      [  107.881631]  [<ffffffff810507b9>] ? trace_hardirqs_on_caller+0x13f/0x172
      [  107.881631]  [<ffffffff812b3d07>] ? _raw_spin_unlock_irqrestore+0x48/0x4d
      [  107.881631]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
      [  107.881631]  [<ffffffff8102f836>] ? __local_bh_enable+0x90/0xa4
      [  107.881631]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
      [  107.881631]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
      [  107.881631]  [<ffffffff812b56bc>] call_softirq+0x1c/0x26
      [  107.881631]  <EOI>  [<ffffffff810033b8>] ? do_softirq+0x46/0x9a
      [  107.881631]  [<ffffffff8106a805>] ? rcu_cpu_kthread+0x2b5/0x2e2
      [  107.881631]  [<ffffffff8102f906>] _local_bh_enable_ip+0xac/0xc9
      [  107.881631]  [<ffffffff8102f93b>] local_bh_enable+0xd/0xf
      [  107.881631]  [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
      [  107.881631]  [<ffffffff81041586>] ? __init_waitqueue_head+0x46/0x46
      [  107.881631]  [<ffffffff8106a550>] ? rcu_yield.constprop.42+0x98/0x98
      [  107.881631]  [<ffffffff81040f0a>] kthread+0x7f/0x87
      [  107.881631]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
      [  107.881631]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
      [  107.881631]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
      [  107.881631]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      8c156c32
    • Andre Guedes's avatar
      Bluetooth: Fix potential deadlock in hci_core · 8aded711
      Andre Guedes authored
      Since hdev->lock may be acquired by threads runnning in interrupt
      context, all threads running in process context should disable
      local bottom halve before locking hdev->lock. This can be done by
      using hci_dev_lock_bh macro.
      
      This way, we avoid potencial deadlocks like this one reported by
      CONFIG_PROVE_LOCKING=y.
      
      [  304.788780] =================================
      [  304.789686] [ INFO: inconsistent lock state ]
      [  304.789686] 2.6.39+ #1
      [  304.789686] ---------------------------------
      [  304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [  304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [  304.789686]  (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686] {SOFTIRQ-ON-W} state was registered at:
      [  304.789686]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
      [  304.789686]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  304.789686]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
      [  304.789686]   [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
      [  304.789686]   [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
      [  304.789686]   [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
      [  304.789686]   [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
      [  304.789686]   [<ffffffff810b1059>] sys_ioctl+0x42/0x65
      [  304.789686]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
      [  304.789686] irq event stamp: 9768
      [  304.789686] hardirqs last  enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
      [  304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
      [  304.789686] softirqs last  enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
      [  304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
      [  304.789686]
      [  304.789686] other info that might help us debug this:
      [  304.789686]  Possible unsafe locking scenario:
      [  304.789686]
      [  304.789686]        CPU0
      [  304.789686]        ----
      [  304.789686]   lock(&(&hdev->lock)->rlock);
      [  304.789686]   <Interrupt>
      [  304.789686]     lock(&(&hdev->lock)->rlock);
      [  304.789686]
      [  304.789686]  *** DEADLOCK ***
      [  304.789686]
      [  304.789686] 1 lock held by ksoftirqd/0/3:
      [  304.789686]  #0:  (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
      [  304.789686]
      [  304.789686] stack backtrace:
      [  304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
      [  304.789686] Call Trace:
      [  304.789686]  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
      [  304.789686]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
      [  304.789686]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
      [  304.789686]  [<ffffffff810504bb>] mark_lock+0x106/0x258
      [  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
      [  304.789686]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
      [  304.789686]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
      [  304.789686]  [<ffffffff812ae126>] ? printk+0x3c/0x3e
      [  304.789686]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
      [  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
      [  304.789686]  [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
      [  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
      [  304.789686]  [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
      [  304.789686]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
      [  304.789686]  [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
      [  304.789686]  [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
      [  304.789686]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
      [  304.789686]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
      [  304.789686]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
      [  304.789686]  [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
      [  304.789686]  [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
      [  304.789686]  [<ffffffff81040f0a>] kthread+0x7f/0x87
      [  304.789686]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
      [  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
      [  304.789686]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
      [  304.789686]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13
      Signed-off-by: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      8aded711
    • Johannes Berg's avatar
      mac80211: fix TKIP replay vulnerability · 34459512
      Johannes Berg authored
      Unlike CCMP, the presence or absence of the QoS
      field doesn't change the encryption, only the
      TID is used. When no QoS field is present, zero
      is used as the TID value. This means that it is
      possible for an attacker to take a QoS packet
      with TID 0 and replay it as a non-QoS packet.
      
      Unfortunately, mac80211 uses different IVs for
      checking the validity of the packet's TKIP IV
      when it checks TID 0 and when it checks non-QoS
      packets. This means it is vulnerable to this
      replay attack.
      
      To fix this, use the same replay counter for
      TID 0 and non-QoS packets by overriding the
      rx->queue value to 0 if it is 16 (non-QoS).
      
      This is a minimal fix for now. I caused this
      issue in
      
      commit 1411f9b5
      Author: Johannes Berg <johannes@sipsolutions.net>
      Date:   Thu Jul 10 10:11:02 2008 +0200
      
          mac80211: fix RX sequence number check
      
      while fixing a sequence number issue (there,
      a separate counter needs to be used).
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      34459512
    • Luciano Coelho's avatar
      mac80211: fix ie memory allocation for scheduled scans · 1186980d
      Luciano Coelho authored
      We were not allocating memory for the IEs passed in the scheduled_scan
      request and this was causing memory corruption (buffer overflow).
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1186980d