linux.git/net/bluetooth, branch v4.4-rc1

Bluetooth: L2CAP: Add missing checks for invalid LE DCID

2015-11-05T03:04:15+00:00

When receiving a connect response we should make sure that the DCID is
within the valid range and that we don't already have another channel
allocated for the same DCID.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: L2CAP: Fix checked range when allocating new CID

2015-11-05T03:04:07+00:00

The 'dyn_end' value is also a valid CID so it should be included in
the range of values checked.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: L2CAP: Fix returning correct LE CoC response codes

2015-11-05T03:04:00+00:00

The core spec defines specific response codes for situations when the
received CID is incorrect. Add the defines for these and return them
as appropriate from the LE Connect Request handler function.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Check for supported white list before issuing commands

2015-11-05T03:03:21+00:00

The white list commands might not be implemented if the controller does
not actually support the white list. So check the supported commands
first before issuing these commands. Not supporting the white list is
the same as supporting a white list with zero size.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

bluetooth: 6lowpan: fix NOHZ: local_softirq_pending

2015-10-27T08:53:36+00:00

Jukka reported about the following warning:

"NOHZ: local_softirq_pending 08"

I remember this warning and we had a similar issue when using workqueues
and calling netif_rx. See commit 5ff3fec ("mac802154: fix NOHZ
local_softirq_pending 08 warning").

This warning occurs when calling "netif_rx" inside the wrong context
(non softirq context). The net core api offers "netif_rx_ni" to call
netif_rx inside the correct softirq context.

Reported-by: Jukka Rissanen 
Signed-off-by: Alexander Aring 
Acked-by: Jukka Rissanen 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix crash on fast disconnect of SCO

2015-10-27T05:00:07+00:00

Fix a crash that may happen when a connection is closed before it was fully
established. Mapping conn->hcon was released by shutdown function, but it
is still referenced in (not yet finished) connection established handling
function.

[ 4635.254073] BUG: unable to handle kernel NULL pointer dereference at 00000013
[ 4635.262058] IP: [] memcmp+0xe/0x25
[ 4635.266835] *pdpt = 0000000024190001 *pde = 0000000000000000
[ 4635.273261] Oops: 0000 [#1] PREEMPT SMP
[ 4635.277652] Modules linked in: evdev ecb vfat fat libcomposite usb2380 isofs zlib_inflate rfcomm(O) udc_core bnep(O) btusb(O) btbcm(O) btintel(O) bluetooth(O) cdc_acm arc4 uinput hid_mule
[ 4635.321761] Pid: 363, comm: kworker/u:2H Tainted: G           O 3.8.0-119.1-plk-adaptation-byt-ivi-brd #1
[ 4635.332642] EIP: 0060:[] EFLAGS: 00010206 CPU: 0
[ 4635.338767] EIP is at memcmp+0xe/0x25
[ 4635.342852] EAX: e4720678 EBX: 00000000 ECX: 00000006 EDX: 00000013
[ 4635.349849] ESI: 00000000 EDI: fb85366c EBP: e40c7dc0 ESP: e40c7db4
[ 4635.356846]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 4635.362873] CR0: 8005003b CR2: 00000013 CR3: 24191000 CR4: 001007f0
[ 4635.369869] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 4635.376865] DR6: ffff0ff0 DR7: 00000400
[ 4635.381143] Process kworker/u:2H (pid: 363, ti=e40c6000 task=e40c5510 task.ti=e40c6000)
[ 4635.390080] Stack:
[ 4635.392319]  e4720400 00000000 fb85366c e40c7df4 fb842285 e40c7de2 fb853200 00000013
[ 4635.401003]  e3f101c4 e4720678 e3f101c0 e403be0a e40c7dfc e416a000 e403be0a fb85366c
[ 4635.409692]  e40c7e1c fb820186 020f6c00 e47c49ac e47c4008 00000000 e416a000 e47c402c
[ 4635.418380] Call Trace:
[ 4635.421153]  [] sco_connect_cfm+0xff/0x236 [bluetooth]
[ 4635.427893]  [] hci_sync_conn_complete_evt.clone.101+0x227/0x268 [bluetooth]
[ 4635.436758]  [] hci_event_packet+0x1caa/0x21d3 [bluetooth]
[ 4635.443859]  [] ? trace_hardirqs_on+0xb/0xd
[ 4635.449502]  [] ? _raw_spin_unlock_irqrestore+0x42/0x59
[ 4635.456340]  [] hci_rx_work+0xb9/0x350 [bluetooth]
[ 4635.462663]  [] ? process_one_work+0x17b/0x2e6
[ 4635.468596]  [] process_one_work+0x1d4/0x2e6
[ 4635.474333]  [] ? process_one_work+0x17b/0x2e6
[ 4635.480294]  [] ? hci_cmd_work+0xda/0xda [bluetooth]
[ 4635.486810]  [] worker_thread+0x171/0x20f
[ 4635.492257]  [] ? complete+0x34/0x3e
[ 4635.497219]  [] kthread+0x90/0x95
[ 4635.501888]  [] ? manage_workers+0x1df/0x1df
[ 4635.507628]  [] ret_from_kernel_thread+0x1b/0x28
[ 4635.513755]  [] ? __init_kthread_worker+0x42/0x42
[ 4635.519975] Code: 74 0d 3c 79 74 04 3c 59 75 0c c6 02 01 eb 03 c6 02 00 31 c0 eb 05 b8 ea ff ff ff 5d c3 55 89 e5 57 56 53 31 db eb 0e 0f b6 34 18 <0f> b6 3c 1a 43 29 fe 75 07 49 85 c9 7f
[ 4635.541264] EIP: [] memcmp+0xe/0x25 SS:ESP 0068:e40c7db4
[ 4635.548166] CR2: 0000000000000013
[ 4635.552177] ---[ end trace e05ce9b8ce6182f6 ]---

Signed-off-by: Kuba Pawlak 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix some obvious coding style issues in the SCO module

2015-10-26T06:22:00+00:00

Lets fix this obvious coding style issues in the SCO module and bring it
in line with the rest of the Bluetooth subsystem.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Replace hci_notify with hci_sock_dev_event

2015-10-26T06:21:47+00:00

There is no point in wrapping hci_sock_dev_event around hci_notify. It
is an empty wrapper which adds no value. So remove it.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Rename bt_cb()->req into bt_cb()->hci

2015-10-26T06:21:03+00:00

The SKB context buffer for HCI request is really not just for requests,
information in their are preserved for the whole HCI layer. So it makes
more sense to actually rename it into bt_cb()->hci and also call it then
struct hci_ctrl.

In addition that allows moving the decoded opcode for outgoing packets
into that struct. So far it was just consuming valuable space from the
main shared items. And opcode are not valid for L2CAP packets.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Remove unneeded parenthesis around MSG_OOB

2015-10-26T06:20:51+00:00

There are two checks that are still using (MSG_OOB) instead of just
MSG_OOB and so lets just fix them.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg