19 Oct, 2011
1 commit
-
The Bluetooth stack has internal connection handlers for all of the various
Bluetooth protocols, and unfortunately, they are currently lacking the LSM
hooks found in the core network stack's connection handlers. I say
unfortunately, because this can cause problems for users who have have an
LSM enabled and are using certain Bluetooth devices. See one problem
report below:* http://bugzilla.redhat.com/show_bug.cgi?id=741703
In order to keep things simple at this point in time, this patch fixes the
problem by cloning the parent socket's LSM attributes to the newly created
child socket. If we decide we need a more elaborate LSM marking mechanism
for Bluetooth (I somewhat doubt this) we can always revisit this decision
in the future.Reported-by: James M. Cape
Signed-off-by: Paul Moore
Acked-by: James Morris
Signed-off-by: David S. Miller
15 Sep, 2011
1 commit
-
The checks for HCI_INQUIRY and HCI_MGMT were in the wrong order,
so that second scans always failed.Signed-off-by: Oliver Neukum
Signed-off-by: Gustavo F. Padovan
12 Aug, 2011
18 commits
-
Once the session thread is running, cleanup must be handled
by the session thread only.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
When an hidp connection is added for a boot protocol input
device, don't release a device reference that was never
acquired. The device reference is acquired when the session
is linked to the session list (which hasn't happened yet when
hidp_setup_input is called).Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
When an hidp connection is added for a boot protocol input
device, only free the allocated device if device registration fails.
Subsequent failures should only unregister the device (the input
device api documents that unregister will also free the allocated
device).Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Free the cached HID report descriptor on thread terminate.
Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Once the session thread is running, cleanup must be
handled by the session thread only.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Commit fada4ac339 introduced the usage of kthread API.
kthread_stop is a blocking function which returns only when
the thread exits. In this case, the thread can't exit because it's
waiting for the write lock, which is being held by cmtp_del_connection()
which is waiting for the thread to exit -- deadlock.Revert cmtp_reset_ctr to its original behavior: non-blocking signalling
for the session to terminate.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Commit f4d7cd4a4c introduced the usage of kthread API.
kthread_stop is a blocking function which returns only when
the thread exits. In this case, the thread can't exit because it's
waiting for the write lock, which is being held by bnep_del_connection()
which is waiting for the thread to exit -- deadlock.Use atomic_t/wake_up_process instead to signal to the thread to exit.
Signed-off-by: Jaikumar Ganesh
Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
No command should be send before Command Complete event for HCI
reset is received. This fix regression introduced by commit
6bd32326cda(Bluetooth: Use proper timer for hci command timout)
for chips whose reset command takes longer to complete (e.g. CSR)
resulting in next command being send before HCI reset completed.Signed-off-by: Szymon Janc
Signed-off-by: Gustavo F. Padovan -
L2CAP connection timeout needs to be assigned as miliseconds
and not as jiffies.Signed-off-by: Chen Ganir
Signed-off-by: Gustavo F. Padovan -
Fix race condition which can result in missing wakeup during
l2cap socket shutdown.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Fix race condition which can result in missing the wakeup intended
to stop the session thread.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Fix race condition which can result in missing the wakeup intended
to stop the session thread.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Fix race conditions which can cause lost wakeups (or missed signals)
while waiting to accept a sco socket connection.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Fix race conditions which can cause lost wakeups (or misssed signals)
while waiting to accept an l2cap socket connection.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Fix race conditions which can cause lost wakeups while waiting
for sock state to change.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Fix race conditions which can cause lost wakeups (or missed
signals) while waiting to accept an rfcomm socket connection.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
Removed superfluous event handling which was used to signal
that the rfcomm kthread had been woken. This appears to have been
used to prevent lost wakeups. Correctly ordering when the task
state is set to TASK_INTERRUPTIBLE is sufficient to prevent lost wakeups.To prevent wakeups which occurred prior to initially setting
TASK_INTERRUPTIBLE from being lost, the main work of the thread loop -
rfcomm_process_sessions() - is performed prior to sleeping.Signed-off-by: Peter Hurley
Signed-off-by: Gustavo F. Padovan -
There was a small typo here so we never actually hit the goto which
would call hci_dev_unlock_bh().Signed-off-by: Dan Carpenter
Signed-off-by: Gustavo F. Padovan
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
