Commit Graph

969 Commits (29c158e81c733ac7d6a75c5ee929f34fb9f92983)

Author SHA1 Message Date
Neil Horman 550fd08c2c net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared
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_flags

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Karsten Keil <isdn@linux-pingi.de>
CC: "David S. Miller" <davem@davemloft.net>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Patrick McHardy <kaber@trash.net>
CC: Krzysztof Halasa <khc@pm.waw.pl>
CC: "John W. Linville" <linville@tuxdriver.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: Marcel Holtmann <marcel@holtmann.org>
CC: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-27 22:39:30 -07:00
David S. Miller 033b1142f4 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
	net/bluetooth/l2cap_core.c
2011-07-21 13:38:42 -07:00
Ilia Kolomisnky 05e9a2f678 Bluetooth: Fix crash with incoming L2CAP connections
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:
[<bf02d5ac>] (l2cap_security_cfm+0x0/0x2ac [bluetooth]) from [<bf01f01c>] (hci_event_pac
ket+0xc2c/0x4aa4 [bluetooth])
[<bf01e3f0>] (hci_event_packet+0x0/0x4aa4 [bluetooth]) from [<bf01a844>] (hci_rx_task+0x
cc/0x27c [bluetooth])
[<bf01a778>] (hci_rx_task+0x0/0x27c [bluetooth]) from [<c008eee4>] (tasklet_action+0xa0/
0x15c)
[<c008ee44>] (tasklet_action+0x0/0x15c) from [<c008f38c>] (__do_softirq+0x98/0x130)
 r7:00000101 r6:00000018 r5:00000001 r4:efc46000
[<c008f2f4>] (__do_softirq+0x0/0x130) from [<c008f524>] (do_softirq+0x4c/0x58)
[<c008f4d8>] (do_softirq+0x0/0x58) from [<c008f5e0>] (run_ksoftirqd+0xb0/0x1b4)
 r4:efc46000 r3:00000001
[<c008f530>] (run_ksoftirqd+0x0/0x1b4) from [<c009f2a8>] (kthread+0x84/0x8c)
 r7:00000000 r6:c008f530 r5:efc47fc4 r4:efc41f08
[<c009f224>] (kthread+0x0/0x8c) from [<c008cc84>] (do_exit+0x0/0x5f0)

Signed-off-by: Ilia Kolomisnky <iliak@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-16 10:14:44 -07:00
Gustavo F. Padovan 9191e6ad89 Bluetooth: Fix regression in L2CAP connection procedure
Caused by the following commit, partially revert it.

commit 9fa7e4f76f
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date:   Thu Jun 30 16:11:30 2011 -0300

    Bluetooth: 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 <luiz.von.dentz@intel.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-16 10:14:44 -07:00
John W. Linville 95a943c162 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
Conflicts:
	net/bluetooth/l2cap_core.c
2011-07-15 10:05:24 -04:00
David S. Miller 6a7ebdf2fd Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
	net/bluetooth/l2cap_core.c
2011-07-14 07:56:40 -07:00
John W. Linville 4b42c542af Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6
Conflicts:
	net/bluetooth/l2cap_core.c
2011-07-11 14:58:22 -04:00
John W. Linville d859898114 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
Conflicts:
	drivers/net/wireless/ath/ath5k/sysfs.c
	net/bluetooth/l2cap_core.c
	net/mac80211/wpa.c
2011-07-11 14:46:59 -04:00
Ilia Kolomisnky e2fd318e3a Bluetooth: Fixes l2cap "command reject" reply according to spec
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 <iliak@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-11 01:43:25 -03:00
Vinicius Costa Gomes 8f36011924 Bluetooth: Add support for returning the encryption key size
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 18:39:31 -03:00
Vinicius Costa Gomes 726b4ffcaa Bluetooth: Add support for storing the key size
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 18:39:19 -03:00
Vinicius Costa Gomes 5a0a8b4974 Bluetooth: Add support for communicating keys with userspace
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 18:38:23 -03:00
Vinicius Costa Gomes 0eb08e3398 Bluetooth: Remove unused field in hci_conn
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:37:22 -03:00
Vinicius Costa Gomes 02bc74556a Bluetooth: Use the stored LTK for restabilishing security
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:37:18 -03:00
Vinicius Costa Gomes e7e62c8592 Bluetooth: Use the link key list to temporarily store the STK
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:37:12 -03:00
Vinicius Costa Gomes 16b908396f Bluetooth: Add support for storing the LTK
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:37:07 -03:00
Vinicius Costa Gomes 54790f73a3 Bluetooth: Fix SM pairing parameters negotiation
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:37:02 -03:00
Vinicius Costa Gomes bea710feff Bluetooth: Reject an encryption request when the key isn't found
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:36:57 -03:00
Vinicius Costa Gomes 75d262c2ad Bluetooth: Add functions to manipulate the link key list for SMP
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:36:31 -03:00
Vinicius Costa Gomes 7034b911af Bluetooth: Add support for SMP phase 3 (key distribution)
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 <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-08 17:07:43 -03:00
Mat Martineau fadd192e81 Bluetooth: Remove L2CAP busy queue
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 <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07 15:29:06 -03:00
Mat Martineau e328140fda Bluetooth: Use event-driven approach for handling ERTM receive buffer
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 <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07 15:28:56 -03:00
Mat Martineau 26f880d221 Bluetooth: Move code for ERTM local busy state to separate functions
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 <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07 15:28:51 -03:00
Andre Guedes 8c156c322f Bluetooth: Fix potential deadlock in mgmt
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: [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631] {SOFTIRQ-ON-W} state was registered at:
[  107.881631]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[  107.881631]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  107.881631]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  107.881631]   [<ffffffffa0011cc2>] mgmt_control+0xd4d/0x175b [bluetooth]
[  107.881631]   [<ffffffffa0013275>] hci_sock_sendmsg+0x97/0x293 [bluetooth]
[  107.881631]   [<ffffffff8121940c>] sock_aio_write+0x126/0x13a
[  107.881631]   [<ffffffff810a35fa>] do_sync_write+0xba/0xfa
[  107.881631]   [<ffffffff810a3beb>] vfs_write+0xaa/0xca
[  107.881631]   [<ffffffff810a3d80>] sys_write+0x45/0x69
[  107.881631]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[  107.881631] irq event stamp: 2100876
[  107.881631] hardirqs last  enabled at (2100876): [<ffffffff812b40d4>] restore_args+0x0/0x30
[  107.881631] hardirqs last disabled at (2100875): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[  107.881631] softirqs last  enabled at (2100862): [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631] softirqs last disabled at (2100863): [<ffffffff812b56bc>] 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]   <Interrupt>
[  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: [<ffffffffa0008353>] 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]  <IRQ>  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[  107.881631]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[  107.881631]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[  107.881631]  [<ffffffff810504bb>] mark_lock+0x106/0x258
[  107.881631]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[  107.881631]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[  107.881631]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
[  107.881631]  [<ffffffff812b3952>] _raw_spin_lock_bh+0x31/0x40
[  107.881631]  [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[  107.881631]  [<ffffffffa000d3fe>] hci_event_packet+0x122b/0x3e12 [bluetooth]
[  107.881631]  [<ffffffff81050658>] ? mark_held_locks+0x4b/0x6d
[  107.881631]  [<ffffffff812b3cff>] ? _raw_spin_unlock_irqrestore+0x40/0x4d
[  107.881631]  [<ffffffff810507b9>] ? trace_hardirqs_on_caller+0x13f/0x172
[  107.881631]  [<ffffffff812b3d07>] ? _raw_spin_unlock_irqrestore+0x48/0x4d
[  107.881631]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[  107.881631]  [<ffffffff8102f836>] ? __local_bh_enable+0x90/0xa4
[  107.881631]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[  107.881631]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[  107.881631]  [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[  107.881631]  <EOI>  [<ffffffff810033b8>] ? do_softirq+0x46/0x9a
[  107.881631]  [<ffffffff8106a805>] ? rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631]  [<ffffffff8102f906>] _local_bh_enable_ip+0xac/0xc9
[  107.881631]  [<ffffffff8102f93b>] local_bh_enable+0xd/0xf
[  107.881631]  [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[  107.881631]  [<ffffffff81041586>] ? __init_waitqueue_head+0x46/0x46
[  107.881631]  [<ffffffff8106a550>] ? rcu_yield.constprop.42+0x98/0x98
[  107.881631]  [<ffffffff81040f0a>] kthread+0x7f/0x87
[  107.881631]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[  107.881631]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  107.881631]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[  107.881631]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07 14:28:29 -03:00
Andre Guedes 8aded7110a Bluetooth: Fix potential deadlock in hci_core
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: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686] {SOFTIRQ-ON-W} state was registered at:
[  304.789686]   [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[  304.789686]   [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  304.789686]   [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  304.789686]   [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
[  304.789686]   [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
[  304.789686]   [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
[  304.789686]   [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
[  304.789686]   [<ffffffff810b1059>] sys_ioctl+0x42/0x65
[  304.789686]   [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[  304.789686] irq event stamp: 9768
[  304.789686] hardirqs last  enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
[  304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[  304.789686] softirqs last  enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
[  304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] 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]   <Interrupt>
[  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: [<ffffffffa0008353>] 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]  [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[  304.789686]  [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[  304.789686]  [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[  304.789686]  [<ffffffff810504bb>] mark_lock+0x106/0x258
[  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  304.789686]  [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[  304.789686]  [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[  304.789686]  [<ffffffff812ae126>] ? printk+0x3c/0x3e
[  304.789686]  [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
[  304.789686]  [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[  304.789686]  [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[  304.789686]  [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
[  304.789686]  [<ffffffff81052615>] ? lock_release+0x16c/0x179
[  304.789686]  [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
[  304.789686]  [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
[  304.789686]  [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[  304.789686]  [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[  304.789686]  [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[  304.789686]  [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[  304.789686]  [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
[  304.789686]  [<ffffffff81040f0a>] kthread+0x7f/0x87
[  304.789686]  [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[  304.789686]  [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[  304.789686]  [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[  304.789686]  [<ffffffff812b55c0>] ? gs_change+0x13/0x13

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-07 14:28:12 -03:00
Andre Guedes 2e65c9d2c5 Bluetooth: Remove enable_smp parameter
The enable_smp parameter is no longer needed. It can be replaced by
checking lmp_host_le_capable.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06 19:10:45 -03:00
Andre Guedes eead27da60 Bluetooth: Add lmp_host_le_capable() macro
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 <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06 19:10:41 -03:00
Andre Guedes e6100a2541 Bluetooth: Add enable_le module parameter
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 <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06 19:10:37 -03:00
Andre Guedes f9b49306dc Bluetooth: Write LE Host Supported command
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 <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06 19:10:32 -03:00
Andre Guedes 971e3a4bbc Bluetooth: Add extfeatures to struct hci_dev
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 <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-06 19:10:27 -03:00
Mat Martineau 02f1b64106 Bluetooth: Check earlier for L2CAP ERTM frames to drop
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 <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-01 16:13:20 -03:00
Gustavo F. Padovan 2461daacb3 Bluetooth: Fix bad locking balance
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-07-01 16:10:06 -03:00
Joe Perches e1447d8d8d Bluetooth: Add bt_printk
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.old

with 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.old

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30 19:17:12 -03:00
Joe Perches e175072f37 Bluetooth: Rename function bt_err to bt_to_errno
Make it easier to use more normal logging styles later.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30 18:44:08 -03:00
Mat Martineau 942ecc9c46 Bluetooth: ERTM timeouts need to be converted to jiffies
ERTM timeouts are defined in milliseconds, but need to be converted
to jiffies when passed to mod_timer().

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30 18:25:43 -03:00
Mat Martineau 774e565146 Bluetooth: Fix indentation whitespace
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30 18:25:33 -03:00
Tomas Targownik 163f4dabea Bluetooth: Fix memory leak under page timeouts
If the remote device is not present, the connections attemp fails and
the struct hci_conn was not freed

Signed-off-by: Tomas Targownik <ttargownik@geicp.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30 16:32:52 -03:00
Gustavo F. Padovan 9fa7e4f76f Bluetooth: 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.

Based on patch from: Ilia Kolomisnky <iliak@ti.com>

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30 16:17:57 -03:00
Peter Hurley 7bb59df83b Bluetooth: Fix hidp disconnect deadlocks and lost wakeup
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 <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-30 15:47:50 -03:00
John W. Linville df2cbe4075 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem 2011-06-30 13:34:06 -04:00
Dan Rosenberg 7ac2881753 Bluetooth: Prevent buffer overflow in l2cap config request
A remote user can provide a small value for the command size field in
the command header of an l2cap configuration request, resulting in an
integer underflow when subtracting the size of the configuration request
header.  This results in copying a very large amount of data via
memcpy() and destroying the kernel heap.  Check for underflow.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-28 14:57:55 -03:00
Randy Dunlap daf4ce85cd bluetooth: uses crypto interfaces, select CRYPTO
Recent changes to hci_core.c use crypto interfaces, so select CRYPTO
to make sure that those interfaces are present.

Fixes these build errors when CRYPTO is not enabled:

net/built-in.o: In function `hci_register_dev':
(.text+0x4cf86): undefined reference to `crypto_alloc_base'
net/built-in.o: In function `hci_unregister_dev':
(.text+0x4f912): undefined reference to `crypto_destroy_tfm'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-06-27 15:09:39 -04:00
Randy Dunlap 9a7b150118 Bluetooth: uses crypto interfaces, select CRYPTO
Recent changes to hci_core.c use crypto interfaces, so select CRYPTO
to make sure that those interfaces are present.

Fixes these build errors when CRYPTO is not enabled:

net/built-in.o: In function `hci_register_dev':
(.text+0x4cf86): undefined reference to `crypto_alloc_base'
net/built-in.o: In function `hci_unregister_dev':
(.text+0x4f912): undefined reference to `crypto_destroy_tfm'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-27 15:12:42 -03:00
John W. Linville 36099365c7 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
Conflicts:
	drivers/net/wireless/rtlwifi/pci.c
	include/linux/netlink.h
2011-06-24 15:25:51 -04:00
Stephen Rothwell f70490e607 Bluetooth: include scatterlist.h where needed
net/bluetooth/smp.c: In function 'smp_e':
net/bluetooth/smp.c:49:21: error: storage size of 'sg' isn't known
net/bluetooth/smp.c:67:2: error: implicit declaration of function 'sg_init_one'
net/bluetooth/smp.c:49:21: warning: unused variable 'sg'

Caused by commit d22ef0bc83 ("Bluetooth: Add LE SMP Cryptoolbox
functions").  Missing include file, presumably.  This batch has been in
the bluetooth tree since June 14, so it may have been exposed by the
removal of linux/mm.h from netdevice.h ...

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-06-24 15:08:48 -04:00
Vinicius Costa Gomes 43f3dc4157 Bluetooth: Fix not setting the chan state
When the connection is ready we should set the connection
to CONNECTED so userspace can use it.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-21 14:55:04 -03:00
Gustavo F. Padovan 0555891184 Merge master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-2.6
Conflicts:
	net/bluetooth/l2cap_core.c
2011-06-21 14:52:56 -03:00
David S. Miller 9f6ec8d697 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
	drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
	drivers/net/wireless/rtlwifi/pci.c
	net/netfilter/ipvs/ip_vs_core.c
2011-06-20 22:29:08 -07:00
Vinicius Costa Gomes e13e21dc5d Bluetooth: Remove useless access to the socket
We already have access to the chan, we don't have to access the
socket to get its imtu.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-20 16:32:11 -03:00
Vinicius Costa Gomes 6312845169 Bluetooth: Fix crash when setting a LE socket to ready
We should not try to do any other type of configuration for
LE links when they become ready.

Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-06-20 16:32:04 -03:00