1. 30 Sep, 2010 4 commits
    • Gustavo F. Padovan's avatar
      Bluetooth: Fix inconsistent lock state with RFCOMM · fad003b6
      Gustavo F. Padovan authored
      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: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      fad003b6
    • Gustavo F. Padovan's avatar
      Bluetooth: Simplify L2CAP Streaming mode sending · ccbb84af
      Gustavo F. Padovan authored
      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: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      ccbb84af
    • Andrei Emeltchenko's avatar
      Bluetooth: fix MTU L2CAP configuration parameter · 8183b775
      Andrei Emeltchenko authored
      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: default avatarAndrei Emeltchenko <andrei.emeltchenko@nokia.com>
      Acked-by: default avatarVille Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      8183b775
    • Mat Martineau's avatar
      Bluetooth: Only enable L2CAP FCS for ERTM or streaming · 8c462b60
      Mat Martineau authored
      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: default avatarMat Martineau <mathewm@codeaurora.org>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      8c462b60
  2. 29 Sep, 2010 2 commits
  3. 28 Sep, 2010 9 commits
  4. 27 Sep, 2010 25 commits