28 Jul, 2011
1 commit
-
After the last patch, We are left in a state in which only drivers calling
ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
hardware call ether_setup for their net_devices and don't hold any state in
their skbs. There are a handful of drivers that violate this assumption of
course, and need to be fixed up. This patch identifies those drivers, and marks
them as not being able to support the safe transmission of skbs by clearning the
IFF_TX_SKB_SHARING flag in priv_flagsSigned-off-by: Neil Horman
CC: Karsten Keil
CC: "David S. Miller"
CC: Jay Vosburgh
CC: Andy Gospodarek
CC: Patrick McHardy
CC: Krzysztof Halasa
CC: "John W. Linville"
CC: Greg Kroah-Hartman
CC: Marcel Holtmann
CC: Johannes Berg
Signed-off-by: David S. Miller
22 Jul, 2011
1 commit
-
Conflicts:
net/bluetooth/l2cap_core.c
17 Jul, 2011
2 commits
-
Another regression fix considering incomming l2cap connections with
defer_setup enabled. In situations when incomming connection is
extracted with l2cap_sock_accept, it's bt_sock info will have
'parent' member zerroed, but 'parent' may be used unconditionally
in l2cap_conn_start() and l2cap_security_cfm() when defer_setup
is enabled.Backtrace:
[] (l2cap_security_cfm+0x0/0x2ac [bluetooth]) from [] (hci_event_pac
ket+0xc2c/0x4aa4 [bluetooth])
[] (hci_event_packet+0x0/0x4aa4 [bluetooth]) from [] (hci_rx_task+0x
cc/0x27c [bluetooth])
[] (hci_rx_task+0x0/0x27c [bluetooth]) from [] (tasklet_action+0xa0/
0x15c)
[] (tasklet_action+0x0/0x15c) from [] (__do_softirq+0x98/0x130)
r7:00000101 r6:00000018 r5:00000001 r4:efc46000
[] (__do_softirq+0x0/0x130) from [] (do_softirq+0x4c/0x58)
[] (do_softirq+0x0/0x58) from [] (run_ksoftirqd+0xb0/0x1b4)
r4:efc46000 r3:00000001
[] (run_ksoftirqd+0x0/0x1b4) from [] (kthread+0x84/0x8c)
r7:00000000 r6:c008f530 r5:efc47fc4 r4:efc41f08
[] (kthread+0x0/0x8c) from [] (do_exit+0x0/0x5f0)Signed-off-by: Ilia Kolomisnky
Signed-off-by: Gustavo F. Padovan
Signed-off-by: David S. Miller -
Caused by the following commit, partially revert it.
commit 9fa7e4f76f3658ba1f44fbdb95c77e7df3f53f95
Author: Gustavo F. Padovan
Date: Thu Jun 30 16:11:30 2011 -0300Bluetooth: Fix regression with incoming L2CAP connections
PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that
( probably after the df3c3931e commit ) the l2cap connection
could not be established in case when the "Auth Complete" HCI
event does not arive before the initiator send "Configuration
request", in which case l2cap replies with "Command rejected"
since the channel is still in BT_CONNECT2 state.Signed-off-by: Luiz Augusto von Dentz
Signed-off-by: Gustavo F. Padovan
Signed-off-by: David S. Miller
15 Jul, 2011
1 commit
-
…wireless-next-2.6 into for-davem
Conflicts:
net/bluetooth/l2cap_core.c
14 Jul, 2011
1 commit
-
Conflicts:
net/bluetooth/l2cap_core.c
12 Jul, 2011
2 commits
-
Conflicts:
net/bluetooth/l2cap_core.c -
Conflicts:
drivers/net/wireless/ath/ath5k/sysfs.c
net/bluetooth/l2cap_core.c
net/mac80211/wpa.c
11 Jul, 2011
1 commit
-
There can 3 reasons for the "command reject" reply produced
by the stack. Each such reply should be accompanied by the
relevand data ( as defined in spec. ). Currently there is one
instance of "command reject" reply with reason "invalid cid"
wich is fixed. Also, added clean-up definitions related to the
"command reject" replies.Signed-off-by: Ilia Kolomisnky
Signed-off-by: Gustavo F. Padovan
09 Jul, 2011
11 commits
-
This will be useful when userspace wants to restrict some kinds of
operations based on the length of the key size used to encrypt the
link.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
In some cases it will be useful having the key size used for
encrypting the link. For example, some profiles may restrict
some operations depending on the key length.The key size is stored in the key that is passed to userspace
using the pin_length field in the key structure.For now this field is only valid for LE controllers. 3.0+HS
controllers define the Read Encryption Key Size command, this
field is intended for storing the value returned by that
command.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
As the key format has changed to something that has a dynamic size,
the way that keys are received and sent must be changed.The structure fields order is changed to make the parsing of the
information received from the Management Interface easier.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
Now that it's possible that the exchanged key is present in
the link key list, we may be able to estabilish security with
an already existing key, without need to perform any SMP
procedure.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
With this we can use only one place to store all keys, without
need to use a field in the connection structure for this
purpose.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
Now when the LTK is received from the remote or generated it is stored,
so it can later be used.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
Before implementing SM key distribution, the pairing features
exchange must be better negotiated, taking into account some
features of the host and connection requirements.If we are in the "not pairable" state, it makes no sense to
exchange any key. This allows for simplification of the key
negociation method.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
Now that we have methods to finding keys by its parameters we can
reject an encryption request if the key isn't found.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
As the LTK (the new type of key being handled now) has more data
associated with it, we need to store this extra data and retrieve
the keys based on that data.Methods for searching for a key and for adding a new LTK are
introduced here.Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan -
This adds support for generating and distributing all the keys
specified in the third phase of SMP.This will make possible to re-establish secure connections, resolve
private addresses and sign commands.For now, the values generated are random.
Signed-off-by: Vinicius Costa Gomes
Signed-off-by: Gustavo F. Padovan
08 Jul, 2011
5 commits
-
The ERTM receive buffer is now handled in a way that does not require
the busy queue and the associated polling code.Signed-off-by: Mat Martineau
Signed-off-by: Gustavo F. Padovan -
This change moves most L2CAP ERTM receive buffer handling out of the
L2CAP core and in to the socket code. It's up to the higher layer
(the socket code, in this case) to tell the core when its buffer is
full or has space available. The recv op should always accept
incoming ERTM data or else the connection will go down.Within the socket layer, an skb that does not fit in the socket
receive buffer will be temporarily stored. When the socket is read
from, that skb will be placed in the receive buffer if possible. Once
adequate buffer space becomes available, the L2CAP core is informed
and the ERTM local busy state is cleared.Receive buffer management for non-ERTM modes is unchanged.
Signed-off-by: Mat Martineau
Signed-off-by: Gustavo F. Padovan -
The local busy state is entered and exited based on buffer status in
the socket layer (or other upper layer). This change is in
preparation for general buffer status reports from the socket layer,
which will then be used to change the local busy status.Signed-off-by: Mat Martineau
Signed-off-by: Gustavo F. Padovan -
All threads running in process context should disable local bottom
halve before locking hdev->lock.This patch fix the following message generated when Bluetooh module
is loaded with enable_mgmt=y (CONFIG_PROVE_LOCKING enabled).[ 107.880781] =================================
[ 107.881631] [ INFO: inconsistent lock state ]
[ 107.881631] 2.6.39+ #1
[ 107.881631] ---------------------------------
[ 107.881631] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 107.881631] rcuc0/7 [HC0[0]:SC1[3]:HE1:SE0] takes:
[ 107.881631] (&(&hdev->lock)->rlock){+.?...}, at: [] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] {SOFTIRQ-ON-W} state was registered at:
[ 107.881631] [] __lock_acquire+0x347/0xd52
[ 107.881631] [] lock_acquire+0x8a/0xa7
[ 107.881631] [] _raw_spin_lock+0x2c/0x3b
[ 107.881631] [] mgmt_control+0xd4d/0x175b [bluetooth]
[ 107.881631] [] hci_sock_sendmsg+0x97/0x293 [bluetooth]
[ 107.881631] [] sock_aio_write+0x126/0x13a
[ 107.881631] [] do_sync_write+0xba/0xfa
[ 107.881631] [] vfs_write+0xaa/0xca
[ 107.881631] [] sys_write+0x45/0x69
[ 107.881631] [] system_call_fastpath+0x16/0x1b
[ 107.881631] irq event stamp: 2100876
[ 107.881631] hardirqs last enabled at (2100876): [] restore_args+0x0/0x30
[ 107.881631] hardirqs last disabled at (2100875): [] save_args+0x6a/0x70
[ 107.881631] softirqs last enabled at (2100862): [] rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] softirqs last disabled at (2100863): [] call_softirq+0x1c/0x26
[ 107.881631]
[ 107.881631] other info that might help us debug this:
[ 107.881631] Possible unsafe locking scenario:
[ 107.881631]
[ 107.881631] CPU0
[ 107.881631] ----
[ 107.881631] lock(&(&hdev->lock)->rlock);
[ 107.881631]
[ 107.881631] lock(&(&hdev->lock)->rlock);
[ 107.881631]
[ 107.881631] *** DEADLOCK ***
[ 107.881631]
[ 107.881631] 1 lock held by rcuc0/7:
[ 107.881631] #0: (hci_task_lock){++.-..}, at: [] hci_rx_task+0x49/0x2f3 [bluetooth]
[ 107.881631]
[ 107.881631] stack backtrace:
[ 107.881631] Pid: 7, comm: rcuc0 Not tainted 2.6.39+ #1
[ 107.881631] Call Trace:
[ 107.881631] [] print_usage_bug+0x1e7/0x1f8
[ 107.881631] [] ? save_stack_trace+0x27/0x44
[ 107.881631] [] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[ 107.881631] [] mark_lock+0x106/0x258
[ 107.881631] [] __lock_acquire+0x2d3/0xd52
[ 107.881631] [] ? vprintk+0x3ab/0x3d7
[ 107.881631] [] lock_acquire+0x8a/0xa7
[ 107.881631] [] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [] ? lock_release+0x16c/0x179
[ 107.881631] [] _raw_spin_lock_bh+0x31/0x40
[ 107.881631] [] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [] hci_event_packet+0x122b/0x3e12 [bluetooth]
[ 107.881631] [] ? mark_held_locks+0x4b/0x6d
[ 107.881631] [] ? _raw_spin_unlock_irqrestore+0x40/0x4d
[ 107.881631] [] ? trace_hardirqs_on_caller+0x13f/0x172
[ 107.881631] [] ? _raw_spin_unlock_irqrestore+0x48/0x4d
[ 107.881631] [] hci_rx_task+0xc8/0x2f3 [bluetooth]
[ 107.881631] [] ? __local_bh_enable+0x90/0xa4
[ 107.881631] [] tasklet_action+0x87/0xe6
[ 107.881631] [] __do_softirq+0x9f/0x13f
[ 107.881631] [] call_softirq+0x1c/0x26
[ 107.881631] [] ? do_softirq+0x46/0x9a
[ 107.881631] [] ? rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] [] _local_bh_enable_ip+0xac/0xc9
[ 107.881631] [] local_bh_enable+0xd/0xf
[ 107.881631] [] rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] [] ? __init_waitqueue_head+0x46/0x46
[ 107.881631] [] ? rcu_yield.constprop.42+0x98/0x98
[ 107.881631] [] kthread+0x7f/0x87
[ 107.881631] [] kernel_thread_helper+0x4/0x10
[ 107.881631] [] ? retint_restore_args+0x13/0x13
[ 107.881631] [] ? __init_kthread_worker+0x53/0x53
[ 107.881631] [] ? gs_change+0x13/0x13Signed-off-by: Andre Guedes
Signed-off-by: Gustavo F. Padovan -
Since hdev->lock may be acquired by threads runnning in interrupt
context, all threads running in process context should disable
local bottom halve before locking hdev->lock. This can be done by
using hci_dev_lock_bh macro.This way, we avoid potencial deadlocks like this one reported by
CONFIG_PROVE_LOCKING=y.[ 304.788780] =================================
[ 304.789686] [ INFO: inconsistent lock state ]
[ 304.789686] 2.6.39+ #1
[ 304.789686] ---------------------------------
[ 304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 304.789686] (&(&hdev->lock)->rlock){+.?...}, at: [] hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] {SOFTIRQ-ON-W} state was registered at:
[ 304.789686] [] __lock_acquire+0x347/0xd52
[ 304.789686] [] lock_acquire+0x8a/0xa7
[ 304.789686] [] _raw_spin_lock+0x2c/0x3b
[ 304.789686] [] hci_blacklist_del+0x1f/0x8a [bluetooth]
[ 304.789686] [] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
[ 304.789686] [] sock_ioctl+0x1f2/0x214
[ 304.789686] [] do_vfs_ioctl+0x46c/0x4ad
[ 304.789686] [] sys_ioctl+0x42/0x65
[ 304.789686] [] system_call_fastpath+0x16/0x1b
[ 304.789686] irq event stamp: 9768
[ 304.789686] hardirqs last enabled at (9768): [] restore_args+0x0/0x30
[ 304.789686] hardirqs last disabled at (9767): [] save_args+0x6a/0x70
[ 304.789686] softirqs last enabled at (9726): [] __do_softirq+0x129/0x13f
[ 304.789686] softirqs last disabled at (9739): [] run_ksoftirqd+0x82/0x133
[ 304.789686]
[ 304.789686] other info that might help us debug this:
[ 304.789686] Possible unsafe locking scenario:
[ 304.789686]
[ 304.789686] CPU0
[ 304.789686] ----
[ 304.789686] lock(&(&hdev->lock)->rlock);
[ 304.789686]
[ 304.789686] lock(&(&hdev->lock)->rlock);
[ 304.789686]
[ 304.789686] *** DEADLOCK ***
[ 304.789686]
[ 304.789686] 1 lock held by ksoftirqd/0/3:
[ 304.789686] #0: (hci_task_lock){++.-..}, at: [] hci_rx_task+0x49/0x2f3 [bluetooth]
[ 304.789686]
[ 304.789686] stack backtrace:
[ 304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
[ 304.789686] Call Trace:
[ 304.789686] [] print_usage_bug+0x1e7/0x1f8
[ 304.789686] [] ? save_stack_trace+0x27/0x44
[ 304.789686] [] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[ 304.789686] [] mark_lock+0x106/0x258
[ 304.789686] [] ? retint_restore_args+0x13/0x13
[ 304.789686] [] __lock_acquire+0x2d3/0xd52
[ 304.789686] [] ? vprintk+0x3ab/0x3d7
[ 304.789686] [] ? printk+0x3c/0x3e
[ 304.789686] [] lock_acquire+0x8a/0xa7
[ 304.789686] [] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [] ? __dynamic_pr_debug+0x10c/0x11a
[ 304.789686] [] _raw_spin_lock+0x2c/0x3b
[ 304.789686] [] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [] hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [] hci_event_packet+0x38e/0x3e12 [bluetooth]
[ 304.789686] [] ? lock_release+0x16c/0x179
[ 304.789686] [] ? _raw_read_unlock+0x23/0x27
[ 304.789686] [] ? hci_send_to_sock+0x179/0x188 [bluetooth]
[ 304.789686] [] hci_rx_task+0xc8/0x2f3 [bluetooth]
[ 304.789686] [] tasklet_action+0x87/0xe6
[ 304.789686] [] __do_softirq+0x9f/0x13f
[ 304.789686] [] run_ksoftirqd+0x82/0x133
[ 304.789686] [] ? __do_softirq+0x13f/0x13f
[ 304.789686] [] kthread+0x7f/0x87
[ 304.789686] [] kernel_thread_helper+0x4/0x10
[ 304.789686] [] ? retint_restore_args+0x13/0x13
[ 304.789686] [] ? __init_kthread_worker+0x53/0x53
[ 304.789686] [] ? gs_change+0x13/0x13Signed-off-by: Andre Guedes
Signed-off-by: Gustavo F. Padovan
07 Jul, 2011
5 commits
-
The enable_smp parameter is no longer needed. It can be replaced by
checking lmp_host_le_capable.Signed-off-by: Andre Guedes
Signed-off-by: Gustavo F. Padovan -
Since we have the extended LMP features properly implemented, we
should check the LMP_HOST_LE bit to know if the host supports LE.Signed-off-by: Andre Guedes
Signed-off-by: Gustavo F. Padovan -
This patch adds a new module parameter to enable/disable host LE
support. By default host LE support is disabled.Signed-off-by: Andre Guedes
Signed-off-by: Gustavo F. Padovan -
This patch adds a handler to Write LE Host Supported command complete
events. Once this commands has completed successfully, we should
read the extended LMP features and update the extfeatures field in
hci_dev.Signed-off-by: Andre Guedes
Signed-off-by: Gustavo F. Padovan -
This new field holds the extended LMP features value. Some LE
mechanism such as discovery procedure needs to read the extended
LMP features to work properly.Signed-off-by: Andre Guedes
Signed-off-by: Gustavo F. Padovan
02 Jul, 2011
2 commits
-
Even when the received tx_seq is expected, the frame still needs to be
dropped if the TX window is exceeded or the receiver is in the local
busy state.Signed-off-by: Mat Martineau
Signed-off-by: Gustavo F. Padovan -
Signed-off-by: Gustavo F. Padovan
01 Jul, 2011
8 commits
-
Add a local logging function to emit bluetooth specific
messages. Using vsprintf extension %pV saves code/text
space.Convert the current BT_INFO and BT_ERR macros to use bt_printk.
Remove __func__ from BT_ERR macro (and the uses).
Prefix "Bluetooth: " to BT_ERR
Remove __func__ from BT_DBG as function can be prefixed when
using dynamic_debug.With allyesconfig:
text data bss dec hex filename
129956 8632 36096 174684 2aa5c drivers/bluetooth/built-in.o.new2
134402 8632 36064 179098 2bb9a drivers/bluetooth/built-in.o.old
14778 1012 3408 19198 4afe net/bluetooth/bnep/built-in.o.new2
15067 1012 3408 19487 4c1f net/bluetooth/bnep/built-in.o.old
346595 19163 86080 451838 6e4fe net/bluetooth/built-in.o.new2
353751 19163 86064 458978 700e2 net/bluetooth/built-in.o.old
18483 1172 4264 23919 5d6f net/bluetooth/cmtp/built-in.o.new2
18927 1172 4264 24363 5f2b net/bluetooth/cmtp/built-in.o.old
19237 1172 5152 25561 63d9 net/bluetooth/hidp/built-in.o.new2
19581 1172 5152 25905 6531 net/bluetooth/hidp/built-in.o.old
59461 3884 14464 77809 12ff1 net/bluetooth/rfcomm/built-in.o.new2
61206 3884 14464 79554 136c2 net/bluetooth/rfcomm/built-in.o.oldwith x86 defconfig (and just bluetooth):
$ size net/bluetooth/built-in.o.defconfig.*
text data bss dec hex filename
66358 933 100 67391 1073f net/bluetooth/built-in.o.defconfig.new
66643 933 100 67676 1085c net/bluetooth/built-in.o.defconfig.oldSigned-off-by: Joe Perches
Signed-off-by: Gustavo F. Padovan -
Make it easier to use more normal logging styles later.
Signed-off-by: Joe Perches
Signed-off-by: Gustavo F. Padovan -
ERTM timeouts are defined in milliseconds, but need to be converted
to jiffies when passed to mod_timer().Signed-off-by: Mat Martineau
Signed-off-by: Gustavo F. Padovan -
Signed-off-by: Mat Martineau
Signed-off-by: Gustavo F. Padovan -
If the remote device is not present, the connections attemp fails and
the struct hci_conn was not freedSigned-off-by: Tomas Targownik
Signed-off-by: Gustavo F. Padovan -
PTS test A2DP/SRC/SRC_SET/TC_SRC_SET_BV_02_I revealed that
( probably after the df3c3931e commit ) the l2cap connection
could not be established in case when the "Auth Complete" HCI
event does not arive before the initiator send "Configuration
request", in which case l2cap replies with "Command rejected"
since the channel is still in BT_CONNECT2 state.Based on patch from: Ilia Kolomisnky
Signed-off-by: Gustavo F. Padovan
-
Partial revert of commit aabf6f89. When the hidp session thread
was converted from kernel_thread to kthread, the atomic/wakeups
were replaced with kthread_stop. kthread_stop has blocking semantics
which are inappropriate for the hidp session kthread. In addition,
the kthread signals itself to terminate in hidp_process_hid_control()
- it cannot do this with kthread_stop().Lastly, a wakeup can be lost if the wakeup happens between checking
for the loop exit condition and setting the current state to
TASK_INTERRUPTIBLE. (Without appropriate synchronization mechanisms,
the task state should not be changed between the condition test and
the yield - via schedule() - as this creates a race between the
wakeup and resetting the state back to interruptible.)Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
…wireless-next-2.6 into for-davem
