linux.git/net/bluetooth, branch v2.6.36

Bluetooth: Disallow to change L2CAP_OPTIONS values when connected

2010-10-04T22:28:52+00:00

L2CAP doesn't permit change like MTU, FCS, TxWindow values while the
connection is alive, we can only set that before the
connection/configuration process. That can lead to bugs in the L2CAP
operation.

Signed-off-by: Gustavo F. Padovan

Revert "Bluetooth: Don't accept ConfigReq if we aren't in the BT_CONFIG state"

2010-09-30T15:19:35+00:00

This reverts commit 8cb8e6f1684be13b51f8429b15f39c140326b327.

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: Gustavo F. Padovan

Bluetooth: Fix inconsistent lock state with RFCOMM

2010-09-30T15:19:35+00:00

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: [] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999] {IN-SOFTIRQ-W} state was registered at:
[ 2833.151999]   [] __lock_acquire+0x5b6/0x1560
[ 2833.151999]   [] lock_acquire+0x5a/0x70
[ 2833.151999]   [] _raw_spin_lock+0x2c/0x40
[ 2833.151999]   [] l2cap_conn_start+0x92/0x640 [l2cap]
[ 2833.151999]   [] l2cap_sig_channel+0x6bf/0x1320 [l2cap]
[ 2833.151999]   [] l2cap_recv_frame+0x133/0x770 [l2cap]
[ 2833.151999]   [] l2cap_recv_acldata+0x1cb/0x390 [l2cap]
[ 2833.151999]   [] hci_rx_task+0x2ab/0x450 [bluetooth]
[ 2833.151999]   [] tasklet_action+0xcb/0xe0
[ 2833.151999]   [] __do_softirq+0xae/0x150
[ 2833.151999]   [] call_softirq+0x1c/0x30
[ 2833.151999]   [] do_softirq+0x75/0xb0
[ 2833.151999]   [] irq_exit+0x8d/0xa0
[ 2833.151999]   [] smp_apic_timer_interrupt+0x6b/0xa0
[ 2833.151999]   [] apic_timer_interrupt+0x13/0x20
[ 2833.151999]   [] cpu_idle+0x5a/0xb0
[ 2833.151999]   [] rest_init+0xad/0xc0
[ 2833.151999]   [] start_kernel+0x2dd/0x2e8
[ 2833.151999]   [] x86_64_start_reservations+0xf6/0xfa
[ 2833.151999]   [] x86_64_start_kernel+0xe4/0xeb
[ 2833.151999] irq event stamp: 731
[ 2833.151999] hardirqs last  enabled at (731): [] local_bh_enable_ip+0x82/0xe0
[ 2833.151999] hardirqs last disabled at (729): [] __do_softirq+0xce/0x150
[ 2833.151999] softirqs last  enabled at (730): [] __do_softirq+0xfe/0x150
[ 2833.151999] softirqs last disabled at (711): [] 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: [] rfcomm_run+0x174/0xb20 [rfcomm]
[ 2833.151999]  #1:  (&(&d->lock)->rlock){+.+...}, at: [] 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]  [] print_usage_bug+0x171/0x180
[ 2833.151999]  [] mark_lock+0x333/0x400
[ 2833.151999]  [] __lock_acquire+0x63a/0x1560
[ 2833.151999]  [] ? __lock_acquire+0xb25/0x1560
[ 2833.151999]  [] lock_acquire+0x5a/0x70
[ 2833.151999]  [] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999]  [] _raw_spin_lock+0x2c/0x40
[ 2833.151999]  [] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999]  [] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999]  [] rfcomm_dlc_accept+0x69/0x100 [rfcomm]
[ 2833.151999]  [] rfcomm_check_accept+0x59/0xd0 [rfcomm]
[ 2833.151999]  [] rfcomm_recv_frame+0x9fb/0x1320 [rfcomm]
[ 2833.151999]  [] ? _raw_spin_unlock_irqrestore+0x3b/0x60
[ 2833.151999]  [] ? trace_hardirqs_on_caller+0x13d/0x180
[ 2833.151999]  [] ? trace_hardirqs_on+0xd/0x10
[ 2833.151999]  [] rfcomm_run+0x221/0xb20 [rfcomm]
[ 2833.151999]  [] ? schedule+0x287/0x780
[ 2833.151999]  [] ? rfcomm_run+0x0/0xb20 [rfcomm]
[ 2833.151999]  [] kthread+0x96/0xa0
[ 2833.151999]  [] kernel_thread_helper+0x4/0x10
[ 2833.151999]  [] ? restore_args+0x0/0x30
[ 2833.151999]  [] ? kthread+0x0/0xa0
[ 2833.151999]  [] ? kernel_thread_helper+0x0/0x10

Signed-off-by: Gustavo F. Padovan

Bluetooth: Simplify L2CAP Streaming mode sending

2010-09-30T15:19:35+00:00

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: Gustavo F. Padovan

Bluetooth: fix MTU L2CAP configuration parameter

2010-09-30T15:19:35+00:00

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: Andrei Emeltchenko 
Acked-by: Ville Tervo 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Only enable L2CAP FCS for ERTM or streaming

2010-09-30T15:19:35+00:00

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: Mat Martineau 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Fix incorrect setting of remote_tx_win for L2CAP ERTM

2010-08-10T11:59:11+00:00

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: Mat Martineau 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix endianness issue with L2CAP MPS configuration

2010-08-10T11:59:09+00:00

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: Mat Martineau 
Signed-off-by: Marcel Holtmann

Bluetooth: Check result code of L2CAP information response

2010-08-04T14:25:17+00:00

Check result code of L2CAP information response. Otherwise
it would read invalid feature mask and access invalid memory.

Signed-off-by: Ville Tervo 
Signed-off-by: Marcel Holtmann

Bluetooth: Don't send RFC for Basic Mode if only it is supported

2010-08-04T14:23:00+00:00

If the remote side doesn't support Enhanced Retransmission Mode neither
Streaming Mode, we shall not send the RFC option.

Some devices that only supports Basic Mode do not understanding the RFC
option. This patch fixes the regression found with these devices.

Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Marcel Holtmann