1. 09 7月, 2011 9 次提交
  2. 08 7月, 2011 5 次提交
    • M
      Bluetooth: Remove L2CAP busy queue · fadd192e
      Mat Martineau 提交于
      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: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      fadd192e
    • M
      Bluetooth: Use event-driven approach for handling ERTM receive buffer · e328140f
      Mat Martineau 提交于
      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: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      e328140f
    • M
      Bluetooth: Move code for ERTM local busy state to separate functions · 26f880d2
      Mat Martineau 提交于
      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: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      26f880d2
    • A
      Bluetooth: Fix potential deadlock in mgmt · 8c156c32
      Andre Guedes 提交于
      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: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8c156c32
    • A
      Bluetooth: Fix potential deadlock in hci_core · 8aded711
      Andre Guedes 提交于
      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: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8aded711
  3. 07 7月, 2011 5 次提交
  4. 02 7月, 2011 4 次提交
  5. 01 7月, 2011 4 次提交
  6. 28 6月, 2011 1 次提交
  7. 25 6月, 2011 1 次提交
  8. 23 6月, 2011 11 次提交