linux-toradex.git/net, branch tegra-9.12.11 Linux kernel for Apalis and Colibri modules Bluetooth: Enter active mode before establishing a SCO link. 2009-11-13T22:19:18+00:00 Nick Pelly npelly@google.com 2009-11-13T22:16:32+00:00 201ac2f225a31dffcb05f1db4d609c467c9c694c When in sniff mode with a long interval time (1.28s) it can take 4+ seconds to establish a SCO link. Fix by requesting active mode before requesting SCO connection. This improves SCO setup time to ~500ms. Bluetooth headsets that use a long interval time, and exhibit the long SCO connection time include Motorola H790, HX1 and H17. They have a CSR 2.1 chipset Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and TI1271. Signed-off-by: Nick Pelly <npelly@google.com> 
When in sniff mode with a long interval time (1.28s) it can take 4+ seconds to
establish a SCO link. Fix by requesting active mode before requesting SCO
connection. This improves SCO setup time to ~500ms.

Bluetooth headsets that use a long interval time, and exhibit the long SCO
connection time include Motorola H790, HX1 and H17. They have a CSR 2.1 chipset

Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
TI1271.

Signed-off-by: Nick Pelly <npelly@google.com>
ipv4: Move sk_error_report inside bh_lock_sock in tcp_v4_nuke_addr 2009-10-23T19:21:01+00:00 Colin Cross ccross@android.com 2009-10-23T19:06:42+00:00 35f3f7d1fcee9a695407165de9cfc88da06244e0 When sk_error_report is called, it wakes up the user-space thread, which then calls tcp_close. When the tcp_close is interrupted by the tcp_v4_nuke_addr ioctl thread running tcp_done, it leaks 392 bytes and triggers a WARN_ON. This patch moves the call to sk_error_report inside the bh_lock_sock, which matches the locking used in tcp_v4_err. Signed-off-by: Colin Cross <ccross@android.com> 
When sk_error_report is called, it wakes up the user-space thread, which then
calls tcp_close.  When the tcp_close is interrupted by the tcp_v4_nuke_addr
ioctl thread running tcp_done, it leaks 392 bytes and triggers a WARN_ON.

This patch moves the call to sk_error_report inside the bh_lock_sock, which
matches the locking used in tcp_v4_err.

Signed-off-by: Colin Cross <ccross@android.com>
ipv4: disable bottom halves around call to tcp_done(). 2009-10-23T19:18:04+00:00 Robert Love rlove@google.com 2009-10-19T14:42:35+00:00 3b775374f2de86246e3c585560bf7b1e4006460d Signed-off-by: Robert Love <rlove@google.com> Signed-off-by: Colin Cross <ccross@android.com> 
Signed-off-by: Robert Love <rlove@google.com>
Signed-off-by: Colin Cross <ccross@android.com>
net: ipv4: Fix race in tcp_v4_nuke_addr(). 2009-10-08T19:35:08+00:00 Robert Love rlove@google.com 2009-10-08T19:06:22+00:00 b57ea61c2cc752e991ac7aaf803acfea0f29d288 To fix a recursive deadlock in 2.6.29, we stopped holding the hash table lock across tcp_done() calls. This fixed the deadlock, but introduced a race where the socket could die or change state. Fix: Before unlocking the hash table, we grab a reference to the socket. We can then unlock the hash table without risk of the socket going away. We then lock the socket, which is safe because it is pinned. We can then call tcp_done() without recursive deadlock and without race. Upon return, we unlock the socket and then unpin it, killing it. Change-Id: Idcdae072b48238b01bdbc8823b60310f1976e045 Signed-off-by: Robert Love <rlove@google.com> Acked-by: Dima Zavin <dima@android.com> 
To fix a recursive deadlock in 2.6.29, we stopped holding the hash table lock
across tcp_done() calls. This fixed the deadlock, but introduced a race where
the socket could die or change state.

Fix: Before unlocking the hash table, we grab a reference to the socket. We
can then unlock the hash table without risk of the socket going away. We then
lock the socket, which is safe because it is pinned. We can then call
tcp_done() without recursive deadlock and without race. Upon return, we unlock
the socket and then unpin it, killing it.

Change-Id: Idcdae072b48238b01bdbc8823b60310f1976e045
Signed-off-by: Robert Love <rlove@google.com>
Acked-by: Dima Zavin <dima@android.com>
Bluetooth: Set general bonding security for ACL by default 2009-10-07T10:38:10+00:00 Andrei Emeltchenko andrei.emeltchenko.news@gmail.com 2009-09-03T09:34:19+00:00 f6e195a306555420312a8b39c9d8e3b7bfdaad15 This patch fixes double pairing issues with SSP. It was observed that when pairing with SSP bluez asks confirmation 2 times. http://www.spinics.net/lists/linux-bluetooth/msg02473.html This also causes bug when we initiate SSP connection from Vista. The reason is because bluetoothd does not store link keys since ioctl HCIGETAUTHINFO returns 0. Setting default general bonding fixes these issues. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com> 
This patch fixes double pairing issues with SSP.

It was observed that when pairing with SSP bluez asks confirmation
2 times.
http://www.spinics.net/lists/linux-bluetooth/msg02473.html

This also causes bug when we initiate SSP connection from Vista.

The reason is because bluetoothd does not store link keys since
ioctl  HCIGETAUTHINFO returns 0. Setting default general
bonding fixes these issues.

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko.news@gmail.com>
Bluetooth: Fix connection establishment with low security requirement 2009-09-23T23:34:50+00:00 Marcel Holtmann marcel@holtmann.org 2009-04-28T16:04:55+00:00 bb0e39d99c09a903706c10b2666502f5784b6bd3 The Bluetooth 2.1 specification introduced four different security modes that can be mapped using Legacy Pairing and Simple Pairing. With the usage of Simple Pairing it is required that all connections (except the ones for SDP) are encrypted. So even the low security requirement mandates an encrypted connection when using Simple Pairing. When using Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required since it causes interoperability issues. To support this properly the low security requirement translates into different host controller transactions depending if Simple Pairing is supported or not. However in case of Simple Pairing the command to switch on encryption after a successful authentication is not triggered for the low security mode. This patch fixes this and actually makes the logic to differentiate between Simple Pairing and Legacy Pairing a lot simpler. Based on a report by Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
The Bluetooth 2.1 specification introduced four different security modes
that can be mapped using Legacy Pairing and Simple Pairing. With the
usage of Simple Pairing it is required that all connections (except
the ones for SDP) are encrypted. So even the low security requirement
mandates an encrypted connection when using Simple Pairing. When using
Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
since it causes interoperability issues.

To support this properly the low security requirement translates into
different host controller transactions depending if Simple Pairing is
supported or not. However in case of Simple Pairing the command to
switch on encryption after a successful authentication is not triggered
for the low security mode. This patch fixes this and actually makes
the logic to differentiate between Simple Pairing and Legacy Pairing
a lot simpler.

Based on a report by Ville Tervo <ville.tervo@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Fallback to SCO on error code 0x10 (Connection Accept Timeout). 2009-09-22T23:08:44+00:00 Nick Pelly npelly@google.com 2009-09-22T22:19:46+00:00 8da2b92f45a99ba87959b441a522ce5ebb833d96 This is to support the Motorola HF850 carkit which reports the error code 0x10 for an eSCO attempt, even though it advertises eSCO support. Here is the hcidump: 2009-09-22 15:40:24.492391 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 1 voice setting 0x0060 2009-09-22 15:40:24.493002 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 2009-09-22 15:40:30.594869 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x10 handle 257 bdaddr 00:50:CD:20:C6:84 type eSCO Error: Connection Accept Timeout Exceeded With this patch we will retry with a SCO connection, which succeeds. Unfortunately the Moto HF850 also takes 5 seconds to return the error for the eSCO attempt, so it will still take 5 seconds to fallback to SCO with this patch. Signed-off-by: Nick Pelly <npelly@google.com> 
This is to support the Motorola HF850 carkit which reports the error code 0x10
for an eSCO attempt, even though it advertises eSCO support. Here is the
hcidump:

2009-09-22 15:40:24.492391 < HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
    handle 1 voice setting 0x0060
2009-09-22 15:40:24.493002 > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2009-09-22 15:40:30.594869 > HCI Event: Synchronous Connect Complete (0x2c)
plen 17
    status 0x10 handle 257 bdaddr 00:50:CD:20:C6:84 type eSCO
    Error: Connection Accept Timeout Exceeded

With this patch we will retry with a SCO connection, which succeeds.

Unfortunately the Moto HF850 also takes 5 seconds to return the error for the
eSCO attempt, so it will still take 5 seconds to fallback to SCO with this
patch.

Signed-off-by: Nick Pelly <npelly@google.com>
Bluetooth: Do not call rfcomm_session_put() due to RFCOMM UA on closed socket. 2009-09-22T20:10:51+00:00 Nick Pelly npelly@google.com 2009-09-22T01:20:03+00:00 1048e007842da2d6440679e1ca80f45438a6369d Processing a RFCOMM UA frame when the socket is closed and we were not the RFCOMM initiator would cause rfcomm_session_put() to be called twice during rfcomm_process_rx(). This would cause a kernel panic in rfcomm_session_close. This could be easily reproduced during disconnect with devices such as Motorola H270 that send RFCOMM UA followed quickly by L2CAP disconnect request. This hcidump for this looks like: 2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d 2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57 2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c 2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6 2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041 Avoid calling rfcomm_session_put() twice by skipping this call in rfcomm_recv_ua() if the socket is closed. Signed-off-by: Nick Pelly <npelly@google.com> 
Processing a RFCOMM UA frame when the socket is closed and we were not the
RFCOMM initiator would cause rfcomm_session_put() to be called twice during
rfcomm_process_rx(). This would cause a kernel panic in rfcomm_session_close.

This could be easily reproduced during disconnect with devices such as
Motorola H270 that send RFCOMM UA followed quickly by L2CAP disconnect request.
This hcidump for this looks like:

2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d
2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13)
plen 5
   handle 1 packets 1
2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57
2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13)
plen 5
   handle 1 packets 1
2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12
   L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041

Avoid calling rfcomm_session_put() twice by skipping this call
in rfcomm_recv_ua() if the socket is closed.

Signed-off-by: Nick Pelly <npelly@google.com>
Revert "Bluetooth: Fix kernel panic while disconnecting RFCOMM" 2009-09-22T20:10:49+00:00 Nick Pelly npelly@google.com 2009-09-22T00:52:19+00:00 eca50df0292aaf54b7e91357e20728544b5413c1 This reverts commit 6f505dbe5337e49302574f8d2e65fd83e30f9117. Unfortunately this fix did not address the unbalanced rfcomm_session_put() call, and panics during this disconnect sequence (with Moto H270) 2009-09-21 17:22:37.384811 < ACL data: handle 1 flags 0x02 dlen 22 L2CAP(d): cid 0x0041 len 18 [psm 3] RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 14 fcs 0xeb 0000: 0d 0a 2b 43 49 45 56 3a 20 37 2c 33 0d 0a ..+CIEV: 7,3.. 2009-09-21 17:22:37.502273 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d 2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57 2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 3] RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c 2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 3] RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6 2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041 2009-09-21 17:22:39.029526 < ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0041 2009-09-21 17:22:39.136581 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2009-09-21 17:22:41.337203 > HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 1 reason 0x13 Reason: Remote User Terminated Connection Signed-off-by: Nick Pelly <npelly@google.com> 
This reverts commit 6f505dbe5337e49302574f8d2e65fd83e30f9117.

Unfortunately this fix did not address the unbalanced rfcomm_session_put()
call, and panics during this disconnect sequence (with Moto H270)

2009-09-21 17:22:37.384811 < ACL data: handle 1 flags 0x02 dlen 22
   L2CAP(d): cid 0x0041 len 18 [psm 3]
     RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 14 fcs 0xeb
     0000: 0d 0a 2b 43 49 45 56 3a  20 37 2c 33 0d 0a        ..+CIEV: 7,3..
2009-09-21 17:22:37.502273 > HCI Event: Number of Completed Packets
(0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d
2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets
(0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57
2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets
(0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12
   L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041
2009-09-21 17:22:39.029526 < ACL data: handle 1 flags 0x02 dlen 12
   L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0041
2009-09-21 17:22:39.136581 > HCI Event: Number of Completed Packets
(0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:41.337203 > HCI Event: Disconn Complete (0x05) plen 4
   status 0x00 handle 1 reason 0x13
   Reason: Remote User Terminated Connection

Signed-off-by: Nick Pelly <npelly@google.com>
Bluetooth: Ensure that HCI sysfs add/del is preempt safe 2009-09-20T19:28:01+00:00 Roger Quadros ext-roger.quadros@nokia.com 2009-04-23T11:50:54+00:00 00302ab404a5edcde9820233ff0a8af68e8018e3 Use a different work_struct variables for add_conn() and del_conn() and use single work queue instead of two for adding and deleting connections. It eliminates the following error on a preemptible kernel: [ 204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 204.370697] pgd = c0004000 [ 204.373443] [0000000c] *pgd=00000000 [ 204.378601] Internal error: Oops: 17 [#1] PREEMPT [ 204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps [ 204.438537] CPU: 0 Not tainted (2.6.28-maemo2 #1) [ 204.443664] PC is at klist_put+0x2c/0xb4 [ 204.447601] LR is at klist_put+0x18/0xb4 [ 204.451568] pc : [<c0270f08>] lr : [<c0270ef4>] psr: a0000113 [ 204.451568] sp : cf1b3f10 ip : cf1b3f10 fp : cf1b3f2c [ 204.463104] r10: 00000000 r9 : 00000000 r8 : bf08029c [ 204.468353] r7 : c7869200 r6 : cfbe2690 r5 : c78692c8 r4 : 00000001 [ 204.474945] r3 : 00000001 r2 : cf1b2000 r1 : 00000001 r0 : 00000000 [ 204.481506] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 204.488861] Control: 10c5387d Table: 887fc018 DAC: 00000017 [ 204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0) Signed-off-by: Roger Quadros <ext-roger.quadros@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Use a different work_struct variables for add_conn() and del_conn() and
use single work queue instead of two for adding and deleting connections.

It eliminates the following error on a preemptible kernel:

[  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[  204.370697] pgd = c0004000
[  204.373443] [0000000c] *pgd=00000000
[  204.378601] Internal error: Oops: 17 [#1] PREEMPT
[  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
[  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
[  204.443664] PC is at klist_put+0x2c/0xb4
[  204.447601] LR is at klist_put+0x18/0xb4
[  204.451568] pc : [<c0270f08>]    lr : [<c0270ef4>]    psr: a0000113
[  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
[  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
[  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
[  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
[  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
[  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
[  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)

Signed-off-by: Roger Quadros <ext-roger.quadros@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>