Commit Graph

2591 Commits

Author SHA1 Message Date
Johan Hedberg
fad5fc8959 Bluetooth: Add LE flow control discipline
This patch adds the necessary discipline for reacting to LE L2CAP
Credits packets, sending those packets, and modifying the known credits
accordingly.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:34 -08:00
Johan Hedberg
b1c325c23d Bluetooth: Implement returning of LE L2CAP credits
We should return credits to the remote side whenever they fall below a
certain level (in our case under half of the initially given amount).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:34 -08:00
Johan Hedberg
1f435424ce Bluetooth: Add new BT_SNDMTU and BT_RCVMTU socket options
This patch adds new socket options for LE sockets since the existing
L2CAP_OPTIONS socket option is not usable for LE. For now, the new
socket options also require LE CoC support to be explicitly enabled to
leave some playroom in case something needs to be changed in a backwards
incompatible way.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:34 -08:00
Johan Hedberg
64b4f8dc76 Bluetooth: Limit L2CAP_OPTIONS socket option usage with LE
Most of the values in L2CAP_OPTIONS are not applicable for LE and those
that are have different semantics. It makes therefore sense to
completely block this socket option for LE and add (in a separate patch)
a new socket option for tweaking the values that do make sense (mainly
the send and receive MTU). Legacy user space ATT code still depends on
getsockopt for L2CAP_OPTIONS though so we need to plug a hole for that
for backwards compatibility.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:34 -08:00
Johan Hedberg
0cd75f7ed7 Bluetooth: Track LE L2CAP credits in l2cap_chan
This patch adds tracking of L2CAP connection oriented channel local and
remote credits to struct l2cap_chan and ensures that connect requests
and responses contain the right values.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:34 -08:00
Johan Hedberg
3831971355 Bluetooth: Add LE L2CAP flow control mode
The LE connection oriented channels have their own mode with its own
data transfer rules. In order to implement this properly we need to
distinguish L2CAP channels operating in this mode from other modes.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:34 -08:00
Johan Hedberg
b5ecba6422 Bluetooth: Make l2cap_le_sig_cmd logic consistent
This patch makes the error handling and return logic of l2cap_le_sig_cmd
consistent with its BR/EDR counterpart.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:33 -08:00
Johan Hedberg
3defe01a48 Bluetooth: Add L2CAP Disconnect suppport for LE
The normal L2CAP Disconnect request and response are also used for LE
connection oriented channels. Therefore, we can simply use the existing
handler functions for terminating LE based L2CAP channels.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:33 -08:00
Johan Hedberg
cea04ce35e Bluetooth: Fix L2CAP channel closing for LE connections
Sending of the L2CAP Disconnect request should also be performed for LE
based channels. The proper thing to do is therefore to look at whether
there's a PSM specified for the channel instead of looking at the link
type.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:33 -08:00
Johan Hedberg
27e2d4c8d2 Bluetooth: Add basic LE L2CAP connect request receiving support
This patch adds the necessary boiler plate code to handle receiving
L2CAP connect requests over LE and respond to them with a proper connect
response.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:33 -08:00
Johan Hedberg
791d60f71a Bluetooth: Refactor L2CAP connect rejection to its own function
We'll need to have a separate code path for LE based connection
rejection so it's cleaner to move out the response construction code
into its own function (and later a second one for LE).

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:33 -08:00
Johan Hedberg
ad32a2f5ce Bluetooth: Add smp_sufficient_security helper function
This function is needed both by the smp_conn_security function as well
as upcoming code to check for the security requirements when receiving
an L2CAP connect request over LE.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:33 -08:00
Johan Hedberg
f1496dee9c Bluetooth: Add initial code for LE L2CAP Connect Request
This patch adds the necessary code to send an LE L2CAP Connect Request
and handle its response when user space has provided us with an LE
socket with a PSM instead of a fixed CID.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:33 -08:00
Johan Hedberg
96ac34fb40 Bluetooth: Move LE L2CAP initiator procedure to its own function
Once connection oriented L2CAP channels over LE are supported they will
need a completely separate handling from BR/EDR channels.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:32 -08:00
Johan Hedberg
203e639ecb Bluetooth: Pass command length to LE signaling channel handlers
The LE signaling PDU length is already calculated in the
l2cap_le_sig_channel function so we can just pass the value to the
various handler functions to avoid unnecessary recalculations (byte
order conversions). Right now the only user is the connection parameter
update procedure, but as new LE signaling operations become available
(for connection oriented channels) they will also be able to make use of
the value.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:32 -08:00
Johan Hedberg
a17de2fe02 Bluetooth: Allow l2cap_chan_check_security() to be used for LE links.
With connection oriented L2CAP channels some code paths will be shared
with BR/EDR links. It is therefore necessary to allow the
l2cap_chan_check_security function to be usable also for LE links in
addition to BR/EDR ones. This means that smp_conn_security() needs to be
called instead of hci_conn_security() in the case of an LE link.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:32 -08:00
Johan Hedberg
bf20fd4ec1 Bluetooth: Update l2cap_global_chan_by_psm() to take a link type
Once connection oriented L2CAP channels become possible for LE we need
to be able to specify the link type we're interested in when looking up
L2CAP channels. Therefore, add a link_type parameter to the
l2cap_global_chan_by_psm() function which gets compared to the address
type associated with each l2cap_chan.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:32 -08:00
Johan Hedberg
9149761ad7 Bluetooth: Add module parameter to enable LE CoC support
Along with the L2CAP Connection Oriented Channels features it is now
allowed to use both custom fixed CIDs as well as PSM based (connection
oriented connections). Since the support for this (with the subsequent
patches) is still on an experimental stage, add a module parameter to
enable it.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:32 -08:00
Johan Hedberg
6d3c15da1d Bluetooth: Remove unnecessary braces from one-line if-statement
This patch is just a trivial coding style fix to remove unnecessary
braces from a one-line if-statement.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-05 07:05:32 -08:00
Johan Hedberg
201a5929c8 Bluetooth: Remove dead code from SMP encryption function
The AES cipher is used in ECB mode by SMP and therefore doesn't use an
IV (crypto_blkcipher_ivsize returns 0) so the code trying to set the IV
was never getting called. Simply remove this code to avoid anyone from
thinking it actually makes some difference.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-04 11:09:05 -02:00
Johan Hedberg
e84a6b139b Bluetooth: Remove useless smp_rand function
This function was always just making a single get_random_bytes() call
and always returning the value 0. It's simpler to just call
get_random_bytes() directly where needed.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-04 11:09:05 -02:00
Andre Guedes
3846220b0d Bluetooth: Refactor hci_disconn_complete_evt
hci_disconn_complete_evt() logic is more complicated than what it
should be, making it hard to follow and add new features.

So this patch does some code refactoring by handling the error cases
in the beginning of the function and by moving the main flow into the
first level of function scope. No change is done in the event handling
logic itself.

Besides organizing this messy code, this patch makes easier to add
code for handling LE auto connection (which will be added in a further
patch).

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-12-04 11:09:04 -02:00
Andre Guedes
abf54a506d Bluetooth: Remove unneeded check in hci_disconn_complete_evt()
According to b644ba336 (patch that introduced HCI_CONN_MGMT_CONNECTED
flag), the HCI_CONN_MGMT_CONNECTED flag tracks when mgmt has been
notified about the connection.

That being said, there is no point in calling mgmt_disconnect_failed()
conditionally based on this flag. mgmt_disconnect_failed() removes
pending MGMT_OP_DISCONNECT commands, it doesn't matter if that
connection was notified or not.

Moreover, if the Disconnection Complete event has status then we have
nothing else to do but call mgmt_disconnect_failed() and return.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-12-04 11:09:04 -02:00
Johan Hedberg
84794e119a Bluetooth: Remove unnecessary 'send' parameter from smp_failure()
The send parameter has only been used for determining whether to send a
Pairing Failed PDU or not. However, the function can equally well use
the already existing reason parameter to make this choice and send the
PDU whenever a non-zero value was passed.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-04 11:09:04 -02:00
Andre Guedes
4ebbd53575 Bluetooth: Remove link type check in hci_disconn_complete_evt()
We can safely remove the link type check from hci_disconn_complete_
evt() since this check in not required for mgmt_disconnect_failed()
and mgmt_device_disconnected() does it internally.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-04 11:09:04 -02:00
Andre Guedes
57eb776fea Bluetooth: Add an extra check in mgmt_device_disconnected()
This patch adds an extra check in mgmt_device_disconnected() so we only
send the "Device Disconnected" event if it is ACL_LINK or LE_LINK link
type.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-04 11:09:03 -02:00
Andre Guedes
3655bba8fe Bluetooth: Check address in mgmt_disconnect_failed()
Check the address and address type in mgmt_disconnect_failed() otherwise
we may wrongly fail the MGMT_OP_DISCONNECT command.

Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-12-04 11:09:03 -02:00
Marcel Holtmann
6a070e6e81 Bluetooth: Store supported commands only during setup procedure
The list of supported commands of a controller can not change during
its lifetime. So store the list just once during the setup procedure
and not every time the HCI command is executed.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-12-04 11:09:03 -02:00
Marcel Holtmann
d3d5dd3eb4 Bluetooth: Remove debug statement for features complete event
The complete list of local features are available through debugfs and
so there is no need to add a debug print here.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-12-04 11:09:03 -02:00
Marcel Holtmann
bef34c0aa1 Bluetooth: Set default own address type only during controller setup
The default own address type is currently set at every power on of
a controller. This overwrites the value set via debugfs. To avoid
this issue, set the default own address type only during controller
setup.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-12-04 11:09:02 -02:00
Marcel Holtmann
33337dcb89 Bluetooth: Fix limited discoverable mode for Zeevo modules
There is an old Panasonic module with a Zeevo chip in there that is
not really operating according to Bluetooth core specification when
it comes to setting the IAC LAP for limited discoverable mode.

For reference, this is the vendor information about this module:

  < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
  > HCI Event: Command Complete (0x0e) plen 12
        Read Local Version Information (0x04|0x0001) ncmd 1
          Status: Success (0x00)
          HCI version: Bluetooth 1.2 (0x02) - Revision 196 (0x00c4)
          LMP version: Bluetooth 1.2 (0x02) - Subversion 61 (0x003d)
          Manufacturer: Zeevo, Inc. (18)

The module reports only the support for one IAC at a time. And that
is totally acceptable according to the Bluetooth core specification
since the minimum supported IAC is only one.

  < HCI Command: Read Number of Supported IAC (0x03|0x0038) plen 0
  > HCI Event: Command Complete (0x0e) plen 5
        Read Number of Supported IAC (0x03|0x0038) ncmd 1
          Status: Success (0x00)
          Number of IAC: 1

The problem arises when trying to program two IAC into the module
on a controller that only supports one.

  < HCI Command: Write Current IAC LAP (0x03|0x003a) plen 7
          Number of IAC: 2
          Access code: 0x9e8b00 (Limited Inquiry)
          Access code: 0x9e8b33 (General Inquiry)
  > HCI Event: Command Status (0x0f) plen 4
        Write Current IAC LAP (0x03|0x003a) ncmd 1
          Status: Unknown HCI Command (0x01)

While this looks strange, but according to the Bluetooth core
specification it is a legal operation. The controller has to
ignore the other values and only program as many as it supports.

  This command shall clear any existing IACs and stores Num_Current_IAC
  and the IAC_LAPs in to the controller. If Num_Current_IAC is greater
  than Num_Support_IAC then only the first Num_Support_IAC shall be
  stored in the controller, and a Command Complete event with error
  code Success (0x00) shall be generated.

This specific controller has a bug here and just returns an error. So
in case the number of supported IAC is less than two and the limited
discoverable mode is requested, now only the LIAC is written to
the controller.

  < HCI Command: Write Current IAC LAP (0x03|0x003a) plen 4
          Number of IAC: 1
          Access code: 0x9e8b00 (Limited Inquiry)
  > HCI Event: Command Complete (0x0e) plen 4
        Write Current IAC LAP (0x03|0x003a) ncmd 1
          Status: Success (0x00)

All other controllers that only support one IAC seem to handle this
perfectly fine, but this fix will only write the LIAC for these
controllers as well.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-12-04 11:09:02 -02:00
John W. Linville
7acd71879c Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem 2013-11-21 10:26:17 -05:00
Hannes Frederic Sowa
f3d3342602 net: rework recvmsg handler msg_name and msg_namelen logic
This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys->msg_namelen == 0)
	msg->msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller <davem@davemloft.net>
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-20 21:52:30 -05:00
John W. Linville
32019c739c Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth 2013-11-15 14:18:45 -05:00
Johan Hedberg
86ca9eac31 Bluetooth: Fix rejecting SMP security request in slave role
The SMP security request is for a slave role device to request the
master role device to initiate a pairing request. If we receive this
command while we're in the slave role we should reject it appropriately.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-11-13 11:36:54 -02:00
Seung-Woo Kim
31e8ce80ba Bluetooth: Fix crash in l2cap_chan_send after l2cap_chan_del
Removing a bond and disconnecting from a specific remote device
can cause l2cap_chan_send() is called after l2cap_chan_del() is
called. This causes following crash.

[ 1384.972086] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 1384.972090] pgd = c0004000
[ 1384.972125] [00000008] *pgd=00000000
[ 1384.972137] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 1384.972144] Modules linked in:
[ 1384.972156] CPU: 0 PID: 841 Comm: krfcommd Not tainted 3.10.14-gdf22a71-dirty #435
[ 1384.972162] task: df29a100 ti: df178000 task.ti: df178000
[ 1384.972182] PC is at l2cap_create_basic_pdu+0x30/0x1ac
[ 1384.972191] LR is at l2cap_chan_send+0x100/0x1d4
[ 1384.972198] pc : [<c051d250>]    lr : [<c0521c78>]    psr: 40000113
[ 1384.972198] sp : df179d40  ip : c083a010  fp : 00000008
[ 1384.972202] r10: 00000004  r9 : 0000065a  r8 : 000003f5
[ 1384.972206] r7 : 00000000  r6 : 00000000  r5 : df179e84  r4 : da557000
[ 1384.972210] r3 : 00000000  r2 : 00000004  r1 : df179e84  r0 : 00000000
[ 1384.972215] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[ 1384.972220] Control: 10c53c7d  Table: 5c8b004a  DAC: 00000015
[ 1384.972224] Process krfcommd (pid: 841, stack limit = 0xdf178238)
[ 1384.972229] Stack: (0xdf179d40 to 0xdf17a000)
[ 1384.972238] 9d40: 00000000 da557000 00000004 df179e84 00000004 000003f5 0000065a 00000000
[ 1384.972245] 9d60: 00000008 c0521c78 df179e84 da557000 00000004 da557204 de0c6800 df179e84
[ 1384.972253] 9d80: da557000 00000004 da557204 c0526b7c 00000004 df724000 df179e84 00000004
[ 1384.972260] 9da0: df179db0 df29a100 c083bc48 c045481c 00000001 00000000 00000000 00000000
[ 1384.972267] 9dc0: 00000000 df29a100 00000000 00000000 00000000 00000000 df179e10 00000000
[ 1384.972274] 9de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1384.972281] 9e00: 00000000 00000000 00000000 00000000 df179e4c c000ec80 c0b538c0 00000004
[ 1384.972288] 9e20: df724000 df178000 00000000 df179e84 c0b538c0 00000000 df178000 c07f4570
[ 1384.972295] 9e40: dcad9c00 df179e74 c07f4394 df179e60 df178000 00000000 df179e84 de247010
[ 1384.972303] 9e60: 00000043 c0454dec 00000001 00000004 df315c00 c0530598 00000004 df315c0c
[ 1384.972310] 9e80: ffffc32c 00000000 00000000 df179ea0 00000001 00000000 00000000 00000000
[ 1384.972317] 9ea0: df179ebc 00000004 df315c00 c05df838 00000000 c0530810 c07d08c0 d7017303
[ 1384.972325] 9ec0: 6ec245b9 00000000 df315c00 c0531b04 c07f3fe0 c07f4018 da67a300 df315c00
[ 1384.972332] 9ee0: 00000000 c05334e0 df315c00 df315b80 df315c00 de0c6800 da67a300 00000000
[ 1384.972339] 9f00: de0c684c c0533674 df204100 df315c00 df315c00 df204100 df315c00 c082b138
[ 1384.972347] 9f20: c053385c c0533754 a0000113 df178000 00000001 c083bc48 00000000 c053385c
[ 1384.972354] 9f40: 00000000 00000000 00000000 c05338c4 00000000 df9f0000 df9f5ee4 df179f6c
[ 1384.972360] 9f60: df178000 c0049db4 00000000 00000000 c07f3ff8 00000000 00000000 00000000
[ 1384.972368] 9f80: df179f80 df179f80 00000000 00000000 df179f90 df179f90 df9f5ee4 c0049cfc
[ 1384.972374] 9fa0: 00000000 00000000 00000000 c000f168 00000000 00000000 00000000 00000000
[ 1384.972381] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1384.972388] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00010000 00000600
[ 1384.972411] [<c051d250>] (l2cap_create_basic_pdu+0x30/0x1ac) from [<c0521c78>] (l2cap_chan_send+0x100/0x1d4)
[ 1384.972425] [<c0521c78>] (l2cap_chan_send+0x100/0x1d4) from [<c0526b7c>] (l2cap_sock_sendmsg+0xa8/0x104)
[ 1384.972440] [<c0526b7c>] (l2cap_sock_sendmsg+0xa8/0x104) from [<c045481c>] (sock_sendmsg+0xac/0xcc)
[ 1384.972453] [<c045481c>] (sock_sendmsg+0xac/0xcc) from [<c0454dec>] (kernel_sendmsg+0x2c/0x34)
[ 1384.972469] [<c0454dec>] (kernel_sendmsg+0x2c/0x34) from [<c0530598>] (rfcomm_send_frame+0x58/0x7c)
[ 1384.972481] [<c0530598>] (rfcomm_send_frame+0x58/0x7c) from [<c0530810>] (rfcomm_send_ua+0x98/0xbc)
[ 1384.972494] [<c0530810>] (rfcomm_send_ua+0x98/0xbc) from [<c0531b04>] (rfcomm_recv_disc+0xac/0x100)
[ 1384.972506] [<c0531b04>] (rfcomm_recv_disc+0xac/0x100) from [<c05334e0>] (rfcomm_recv_frame+0x144/0x264)
[ 1384.972519] [<c05334e0>] (rfcomm_recv_frame+0x144/0x264) from [<c0533674>] (rfcomm_process_rx+0x74/0xfc)
[ 1384.972531] [<c0533674>] (rfcomm_process_rx+0x74/0xfc) from [<c0533754>] (rfcomm_process_sessions+0x58/0x160)
[ 1384.972543] [<c0533754>] (rfcomm_process_sessions+0x58/0x160) from [<c05338c4>] (rfcomm_run+0x68/0x110)
[ 1384.972558] [<c05338c4>] (rfcomm_run+0x68/0x110) from [<c0049db4>] (kthread+0xb8/0xbc)
[ 1384.972576] [<c0049db4>] (kthread+0xb8/0xbc) from [<c000f168>] (ret_from_fork+0x14/0x2c)
[ 1384.972586] Code: e3100004 e1a07003 e5946000 1a000057 (e5969008)
[ 1384.972614] ---[ end trace 6170b7ce00144e8c ]---

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-11-13 11:36:54 -02:00
Seung-Woo Kim
8992da0993 Bluetooth: Fix to set proper bdaddr_type for RFCOMM connect
L2CAP socket validates proper bdaddr_type for connect, so this
patch fixes to set explictly bdaddr_type for RFCOMM connect.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-11-13 11:36:53 -02:00
Seung-Woo Kim
c507f138fc Bluetooth: Fix RFCOMM bind fail for L2CAP sock
L2CAP socket bind checks its bdaddr type but RFCOMM kernel thread
does not assign proper bdaddr type for L2CAP sock. This can cause
that RFCOMM failure.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-11-13 11:36:53 -02:00
Marcel Holtmann
60c7a3c9c7 Bluetooth: Fix issue with RFCOMM getsockopt operation
The commit 94a86df010 seem to have
uncovered a long standing bug that did not trigger so far.

BUG: unable to handle kernel paging request at 00000009dd503502
IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ath5k ath mac80211 cfg80211
CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
1202    12/22/2010
task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
RIP: 0010:[<ffffffff815b1868>]  [<ffffffff815b1868>]
rfcomm_sock_getsockopt+0x128/0x200
RSP: 0018:ffff88033046bed8  EFLAGS: 00010246
RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
FS:  00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
Stack:
ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
Call Trace:
[<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
[<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
[<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
RIP  [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
RSP <ffff88033046bed8>
CR2: 00000009dd503502

It triggers in the following segment of the code:

0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
738
739	static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
740	{
741		struct sock *sk = sock->sk;
742		struct rfcomm_conninfo cinfo;
743		struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
744		int len, err = 0;
745		u32 opt;
746
747		BT_DBG("sk %p", sk);

The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
but that socket of course does not contain the low-level connection
details requested here.

Tracking down the actual offending commit, it seems that this has been
introduced when doing some L2CAP refactoring:

commit 8c1d787be4
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date:   Wed Apr 13 20:23:55 2011 -0300

@@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
        struct sock *sk = sock->sk;
        struct sock *l2cap_sk;
        struct rfcomm_conninfo cinfo;
+       struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
        int len, err = 0;
        u32 opt;

@@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u

                l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;

-               cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
-               memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
+               cinfo.hci_handle = conn->hcon->handle;
+               memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);

The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
now causing a problem within getsocketopt() system call. To fix this,
just re-introduce l2cap_sk and make sure the right socket is used for
the low-level connection details.

Reported-by: Fabio Rossi <rossi.f@inwind.it>
Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Tested-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-11-13 11:36:52 -02:00
John W. Linville
c1f3bb6bd3 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem 2013-11-08 09:03:10 -05:00
John W. Linville
87bc0728d4 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
Conflicts:
	drivers/net/wireless/brcm80211/brcmfmac/sdio_host.h
2013-11-04 14:51:28 -05:00
Gustavo Padovan
d78a32a8fc Bluetooth: Remove sk member from struct l2cap_chan
There is no access to chan->sk in L2CAP core now. This change marks the
end of the task of splitting L2CAP between Core and Socket, thus sk is now
gone from struct l2cap_chan.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 13:50:56 -07:00
Gustavo Padovan
7f5396a774 Bluetooth: Use bt_cb(skb)->chan to send raw data back
Instead of accessing skb->sk in L2CAP core we now compare the channel
a skb belongs to and not send it back if the channel is same. This change
removes another struct socket usage from L2CAP core.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 13:50:55 -07:00
Gustavo Padovan
0e790c64f3 Bluetooth: Add L2CAP channel to skb private data
Adding the channel to the skb private data makes possible to us know which
channel the skb we have came from.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 13:50:55 -07:00
Gustavo Padovan
8ffb929098 Bluetooth: Remove parent socket usage from l2cap_core.c
The parent socket is not used inside the L2CAP core anymore. We only lock
it to indirect access through the new_connection() callback. The hold of
the socket lock was moved to the new_connection() callback.

Inside L2CAP core the channel lock is now used in l2cap_le_conn_ready()
and l2cap_conn_ready() to protect the execution of these two functions
during the handling of new incoming connections.

This change remove the socket lock usage from L2CAP core while keeping
the code safe against race conditions.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 12:58:17 -07:00
Gustavo Padovan
f93fa27323 Bluetooth: Remove socket lock from l2cap_state_change()
This simplify and make safer the state change handling inside l2cap_core.c.
we got rid of __l2cap_state_change(). And l2cap_state_change() doesn't lock
the socket anymore, instead the socket is locked inside the ops callback for
state change in l2cap_sock.c.

It makes the code safer because in some we were using a unlocked version,
and now we are calls to l2cap_state_change(), when dealing with sockets, use
the locked version.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 12:58:17 -07:00
Gustavo Padovan
acdcabf532 Bluetooth: Hold socket in defer callback in L2CAP socket
In both places that we use the defer callback the socket lock is held for
a indirect sk access inside __l2cap_change_state() and chan->ops->defer(),
all the rest of the code between lock_sock() and release_sock() is
already protected by the channel lock and won't be affected by this
change.

We now use l2cap_change_state(), the locked version of the change state
function, and the defer callback does the locking itself now. This does
not affect other uses of the defer callback.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 12:58:17 -07:00
Gustavo Padovan
0f2c615374 Bluetooth: Do not access chan->sk directly
In the process of removing socket usage from L2CAP we now access the L2CAP
socket from the data member of struct l2cap_chan. For the L2CAP socket
user the data member points to the L2CAP socket.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 12:58:16 -07:00
Gustavo Padovan
d42970f319 Bluetooth: Remove not used struct sock
It is a leftover from the recent effort of remove sk usage from L2CAP
core.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 12:58:16 -07:00
Johan Hedberg
547003b114 Bluetooth: Fix enabling fast connectable on LE-only controllers
The current "fast connectable" feature is BR/EDR-only, so add a proper
check for BR/EDR support before proceeding with the associated HCI
commands.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-21 07:18:27 -07:00