1. 12 10月, 2010 3 次提交
  2. 05 10月, 2010 1 次提交
  3. 30 9月, 2010 5 次提交
    • G
      Revert "Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state" · b0239c80
      Gustavo F. Padovan 提交于
      This reverts commit 8cb8e6f1.
      
      That commit introduced a regression with the Bluetooth Profile Tuning
      Suite(PTS), Reverting this make sure that L2CAP is in a qualificable
      state.
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      b0239c80
    • G
      Bluetooth: Fix inconsistent lock state with RFCOMM · fad003b6
      Gustavo F. Padovan 提交于
      When receiving a rfcomm connection with the old dund deamon a
      inconsistent lock state happens. That's because interrupts were already
      disabled by l2cap_conn_start() when rfcomm_sk_state_change() try to lock
      the spin_lock.
      
      As result we may have a inconsistent lock state for l2cap_conn_start()
      after rfcomm_sk_state_change() calls bh_lock_sock() and disable interrupts
      as well.
      
      [ 2833.151999]
      [ 2833.151999] =================================
      [ 2833.151999] [ INFO: inconsistent lock state ]
      [ 2833.151999] 2.6.36-rc3 #2
      [ 2833.151999] ---------------------------------
      [ 2833.151999] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      [ 2833.151999] krfcommd/2306 [HC0[0]:SC0[0]:HE1:SE1] takes:
      [ 2833.151999]  (slock-AF_BLUETOOTH){+.?...}, at: [<ffffffffa00bcb56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
      [ 2833.151999] {IN-SOFTIRQ-W} state was registered at:
      [ 2833.151999]   [<ffffffff81094346>] __lock_acquire+0x5b6/0x1560
      [ 2833.151999]   [<ffffffff8109534a>] lock_acquire+0x5a/0x70
      [ 2833.151999]   [<ffffffff81392b6c>] _raw_spin_lock+0x2c/0x40
      [ 2833.151999]   [<ffffffffa00a5092>] l2cap_conn_start+0x92/0x640 [l2cap]
      [ 2833.151999]   [<ffffffffa00a6a3f>] l2cap_sig_channel+0x6bf/0x1320 [l2cap]
      [ 2833.151999]   [<ffffffffa00a9173>] l2cap_recv_frame+0x133/0x770 [l2cap]
      [ 2833.151999]   [<ffffffffa00a997b>] l2cap_recv_acldata+0x1cb/0x390 [l2cap]
      [ 2833.151999]   [<ffffffffa000db4b>] hci_rx_task+0x2ab/0x450 [bluetooth]
      [ 2833.151999]   [<ffffffff8106b22b>] tasklet_action+0xcb/0xe0
      [ 2833.151999]   [<ffffffff8106b91e>] __do_softirq+0xae/0x150
      [ 2833.151999]   [<ffffffff8102bc0c>] call_softirq+0x1c/0x30
      [ 2833.151999]   [<ffffffff8102ddb5>] do_softirq+0x75/0xb0
      [ 2833.151999]   [<ffffffff8106b56d>] irq_exit+0x8d/0xa0
      [ 2833.151999]   [<ffffffff8104484b>] smp_apic_timer_interrupt+0x6b/0xa0
      [ 2833.151999]   [<ffffffff8102b6d3>] apic_timer_interrupt+0x13/0x20
      [ 2833.151999]   [<ffffffff81029dfa>] cpu_idle+0x5a/0xb0
      [ 2833.151999]   [<ffffffff81381ded>] rest_init+0xad/0xc0
      [ 2833.151999]   [<ffffffff817ebc4d>] start_kernel+0x2dd/0x2e8
      [ 2833.151999]   [<ffffffff817eb2e6>] x86_64_start_reservations+0xf6/0xfa
      [ 2833.151999]   [<ffffffff817eb3ce>] x86_64_start_kernel+0xe4/0xeb
      [ 2833.151999] irq event stamp: 731
      [ 2833.151999] hardirqs last  enabled at (731): [<ffffffff8106b762>] local_bh_enable_ip+0x82/0xe0
      [ 2833.151999] hardirqs last disabled at (729): [<ffffffff8106b93e>] __do_softirq+0xce/0x150
      [ 2833.151999] softirqs last  enabled at (730): [<ffffffff8106b96e>] __do_softirq+0xfe/0x150
      [ 2833.151999] softirqs last disabled at (711): [<ffffffff8102bc0c>] call_softirq+0x1c/0x30
      [ 2833.151999]
      [ 2833.151999] other info that might help us debug this:
      [ 2833.151999] 2 locks held by krfcommd/2306:
      [ 2833.151999]  #0:  (rfcomm_mutex){+.+.+.}, at: [<ffffffffa00bb744>] rfcomm_run+0x174/0xb20 [rfcomm]
      [ 2833.151999]  #1:  (&(&d->lock)->rlock){+.+...}, at: [<ffffffffa00b9223>] rfcomm_dlc_accept+0x53/0x100 [rfcomm]
      [ 2833.151999]
      [ 2833.151999] stack backtrace:
      [ 2833.151999] Pid: 2306, comm: krfcommd Tainted: G        W   2.6.36-rc3 #2
      [ 2833.151999] Call Trace:
      [ 2833.151999]  [<ffffffff810928e1>] print_usage_bug+0x171/0x180
      [ 2833.151999]  [<ffffffff810936c3>] mark_lock+0x333/0x400
      [ 2833.151999]  [<ffffffff810943ca>] __lock_acquire+0x63a/0x1560
      [ 2833.151999]  [<ffffffff810948b5>] ? __lock_acquire+0xb25/0x1560
      [ 2833.151999]  [<ffffffff8109534a>] lock_acquire+0x5a/0x70
      [ 2833.151999]  [<ffffffffa00bcb56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
      [ 2833.151999]  [<ffffffff81392b6c>] _raw_spin_lock+0x2c/0x40
      [ 2833.151999]  [<ffffffffa00bcb56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
      [ 2833.151999]  [<ffffffffa00bcb56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
      [ 2833.151999]  [<ffffffffa00b9239>] rfcomm_dlc_accept+0x69/0x100 [rfcomm]
      [ 2833.151999]  [<ffffffffa00b9a49>] rfcomm_check_accept+0x59/0xd0 [rfcomm]
      [ 2833.151999]  [<ffffffffa00bacab>] rfcomm_recv_frame+0x9fb/0x1320 [rfcomm]
      [ 2833.151999]  [<ffffffff813932bb>] ? _raw_spin_unlock_irqrestore+0x3b/0x60
      [ 2833.151999]  [<ffffffff81093acd>] ? trace_hardirqs_on_caller+0x13d/0x180
      [ 2833.151999]  [<ffffffff81093b1d>] ? trace_hardirqs_on+0xd/0x10
      [ 2833.151999]  [<ffffffffa00bb7f1>] rfcomm_run+0x221/0xb20 [rfcomm]
      [ 2833.151999]  [<ffffffff813905e7>] ? schedule+0x287/0x780
      [ 2833.151999]  [<ffffffffa00bb5d0>] ? rfcomm_run+0x0/0xb20 [rfcomm]
      [ 2833.151999]  [<ffffffff81081026>] kthread+0x96/0xa0
      [ 2833.151999]  [<ffffffff8102bb14>] kernel_thread_helper+0x4/0x10
      [ 2833.151999]  [<ffffffff813936bc>] ? restore_args+0x0/0x30
      [ 2833.151999]  [<ffffffff81080f90>] ? kthread+0x0/0xa0
      [ 2833.151999]  [<ffffffff8102bb10>] ? kernel_thread_helper+0x0/0x10
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      fad003b6
    • G
      Bluetooth: Simplify L2CAP Streaming mode sending · ccbb84af
      Gustavo F. Padovan 提交于
      As we don't have any error control on the Streaming mode, i.e., we don't
      need to keep a copy of the skb for later resending we don't need to
      call skb_clone() on it.
      Then we can go one further here, and dequeue the skb before sending it,
      that also means we don't need to look to sk->sk_send_head anymore.
      
      The patch saves memory and time when sending Streaming mode data, so
      it is good to mainline.
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      ccbb84af
    • A
      Bluetooth: fix MTU L2CAP configuration parameter · 8183b775
      Andrei Emeltchenko 提交于
      When receiving L2CAP negative configuration response with respect
      to MTU parameter we modify wrong field. MTU here means proposed
      value of MTU that the remote device intends to transmit. So for local
      L2CAP socket it is pi->imtu.
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com>
      Acked-by: NVille Tervo <ville.tervo@nokia.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8183b775
    • M
      Bluetooth: Only enable L2CAP FCS for ERTM or streaming · 8c462b60
      Mat Martineau 提交于
      This fixes a bug which caused the FCS setting to show L2CAP_FCS_CRC16
      with L2CAP modes other than ERTM or streaming.  At present, this only
      affects the FCS value shown with getsockopt() for basic mode.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      8c462b60
  4. 24 9月, 2010 1 次提交
  5. 07 9月, 2010 1 次提交
  6. 10 8月, 2010 2 次提交
    • M
      Bluetooth: Fix incorrect setting of remote_tx_win for L2CAP ERTM · cff70fae
      Mat Martineau 提交于
      remote_tx_win is intended to be set on receipt of an L2CAP
      configuration request.  The value is used to determine the size of the
      transmit window on the remote side of an ERTM connection, so L2CAP
      can stop sending frames when that remote window is full.
      
      An incorrect remote_tx_win value will cause the stack to not fully
      utilize the tx window (performance impact), or to overfill the remote
      tx window (causing dropped frames or a disconnect).
      
      This patch removes an extra setting of remote_tx_win when a
      configuration response is received.  The transmit window has a
      different meaning in a response - it is an informational value
      less than or equal to the local tx_win.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cff70fae
    • M
      Bluetooth: Fix endianness issue with L2CAP MPS configuration · 86b1b263
      Mat Martineau 提交于
      Incoming configuration values must be converted to native CPU order
      before use.  This fixes a bug where a little-endian MPS value is
      compared to a native CPU value.  On big-endian processors, this
      can cause ERTM and streaming mode segmentation to produce PDUs
      that are larger than the remote stack is expecting, or that would
      produce fragmented skbs that the current FCS code cannot handle.
      Signed-off-by: NMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      86b1b263
  7. 04 8月, 2010 2 次提交
  8. 01 8月, 2010 2 次提交
  9. 28 7月, 2010 3 次提交
  10. 22 7月, 2010 20 次提交