- 13 Feb, 2012 40 commits
-
-
Hemant Gupta authored
This patch sends correct IO Capability response to remote device in case Local Device supports KeyBoardDisplay IO Capability as this capability is not valid as per BT spec for IO capability Request Reply Command. This capability is mapped to DisplayYesNo which is in accordance with BT spec. Signed-off-by:
Hemant Gupta <hemant.gupta@stericsson.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Peter Hurley authored
Commit 33060542 fixed l2cap conn establishment for non-ssp remote devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security is tested (which was always returning failure on any subsequent security checks). However, this broke l2cap conn establishment for ssp remote devices when an ACL link was already established at SDP-level security. This fix ensures that encryption must be pending whenever authentication is also pending. Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Tested-by:
Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by:
-
Johan Hedberg authored
This patch updates the opcodes for mgmt commands and events to match the latest user space API specification. Signed-off-by:
-
Vinicius Costa Gomes authored
We only should try to free the SMP channel that was created if there is a pending SMP session. Signed-off-by:
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Acked-by:
-
Octavian Purdila authored
There is an imbalance in the rfcomm_session_hold / rfcomm_session_put operations which causes the following crash: [ 685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b [ 685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e [ 685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000 [ 685.010191] Oops: 0000 [#1] PREEMPT SMP [ 685.010247] [ 685.010255] Pid: 947, comm: krfcommd Tainted: G C 3.0.16-mid8-dirty #44 [ 685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1 [ 685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e [ 685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4 [ 685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50 [ 685.010295] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000) [ 685.010308] Stack: [ 685.010312] ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10 [ 685.010331] 00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000 [ 685.010348] 00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000 [ 685.010367] Call Trace: [ 685.010376] [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74 [ 685.010387] [<c149ec10>] rfcomm_process_sessions+0xb7/0xde [ 685.010398] [<c149ec87>] rfcomm_run+0x50/0x6d [ 685.010409] [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde [ 685.010419] [<c104fe01>] kthread+0x63/0x68 [ 685.010431] [<c104fd9e>] ? __init_kthread_worker+0x42/0x42 [ 685.010442] [<c14dae82>] kernel_thread_helper+0x6/0xd This issue has been brought up earlier here: https://lkml.org/lkml/2011/5/21/127 The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This operation doesn't seem be to required as for the non-initiator case we have the rfcomm_process_rx doing an explicit put and in the initiator case the last dlc_unlink will drive the reference counter to 0. There have been several attempts to fix these issue: 6c2718da Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket 683d949a Bluetooth: Never deallocate a session when some DLC points to it but AFAICS they do not fix the issue just make it harder to reproduce. Signed-off-by:
Octavian Purdila <octavian.purdila@intel.com> Signed-off-by:
Gopala Krishna Murala <gopala.krishna.murala@intel.com> Acked-by:
-
Andre Guedes authored
This function is not called in interrupt context anymore, so it should use GFP_KERNEL to allocate memory. Signed-off-by:
Andre Guedes <aguedespe@gmail.com> Acked-by:
-
Vinicius Costa Gomes authored
This makes clear that this is the size of the key used to encrypt the link. Signed-off-by:
-
Vinicius Costa Gomes authored
This defines two new messages, one event that will inform userspace that a new Long Term Key was exchanged and one that will allow userspace to load LTKs into the kernel. Besides the information necessary for the restablishement of the secure link, we added some extra information: "authenticated" that informs if the key can be used to establish an authenticated link, and "master" that informs the role in that the key should be used. Signed-off-by:
-
Ulisses Furquim authored
We need to use the _sync() version for cancelling the info and security timer in the L2CAP connection delete path. Otherwise the delayed work handler might run after the connection object is freed. Signed-off-by:
Ulisses Furquim <ulisses@profusion.mobi> Acked-by:
-
Ulisses Furquim authored
__cancel_delayed_work() is being used in some paths where we cannot sleep waiting for the delayed work to finish. However, that function might return while the timer is running and the work will be queued again. Replace the calls with safer cancel_delayed_work() version which spins until the timer handler finishes on other CPUs and cancels the delayed work. Signed-off-by:
-
Andre Guedes authored
We don't need locking hdev in hci_conn_timeout() since it doesn't access any hdev's shared resources, it basically queues HCI commands. Signed-off-by:
Andre Guedes <andre.guedes@openbossa.org> Signed-off-by:
-
Andre Guedes authored
We don't need to use the _sync variant in hci_conn_hold and hci_conn_put to cancel conn->disc_work delayed work. This way we avoid potential deadlocks like this one reported by lockdep. ====================================================== [ INFO: possible circular locking dependency detected ] 3.2.0+ #1 Not tainted ------------------------------------------------------- kworker/u:1/17 is trying to acquire lock: (&hdev->lock){+.+.+.}, at: [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] but task is already holding lock: ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((&(&conn->disc_work)->work)){+.+...}: [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff81034ed1>] wait_on_work+0x3d/0xaa [<ffffffff81035b54>] __cancel_work_timer+0xac/0xef [<ffffffff81035ba4>] cancel_delayed_work_sync+0xd/0xf [<ffffffffa00554b0>] smp_chan_create+0xde/0xe6 [bluetooth] [<ffffffffa0056160>] smp_conn_security+0xa3/0x12d [bluetooth] [<ffffffffa0053640>] l2cap_connect_cfm+0x237/0x2e8 [bluetooth] [<ffffffffa004239c>] hci_proto_connect_cfm+0x2d/0x6f [bluetooth] [<ffffffffa0046ea5>] hci_event_packet+0x29d1/0x2d60 [bluetooth] [<ffffffffa003dde3>] hci_rx_work+0xd0/0x2e1 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 -> #1 (slock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}: [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff812e553a>] _raw_spin_lock_bh+0x36/0x6a [<ffffffff81244d56>] lock_sock_nested+0x24/0x7f [<ffffffffa004d96f>] lock_sock+0xb/0xd [bluetooth] [<ffffffffa0052906>] l2cap_chan_connect+0xa9/0x26f [bluetooth] [<ffffffffa00545f8>] l2cap_sock_connect+0xb3/0xff [bluetooth] [<ffffffff81243b48>] sys_connect+0x69/0x8a [<ffffffff812e6579>] system_call_fastpath+0x16/0x1b -> #0 (&hdev->lock){+.+.+.}: [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74 [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31 [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 other info that might help us debug this: Chain exists of: &hdev->lock --> slock-AF_BLUETOOTH-BTPROTO_L2CAP --> (&(&conn->disc_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((&(&conn->disc_work)->work)); lock(slock-AF_BLUETOOTH-BTPROTO_L2CAP); lock((&(&conn->disc_work)->work)); lock(&hdev->lock); *** DEADLOCK *** 2 locks held by kworker/u:1/17: #0: (hdev->name){.+.+.+}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf #1: ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf stack backtrace: Pid: 17, comm: kworker/u:1 Not tainted 3.2.0+ #1 Call Trace: [<ffffffff812e06c6>] print_circular_bug+0x1f8/0x209 [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74 [<ffffffff81021ef2>] ? arch_local_irq_restore+0x6/0xd [<ffffffff81022bc7>] ? vprintk+0x3f9/0x41e [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff81190fd6>] ? __dynamic_pr_debug+0x6d/0x6f [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff8105320f>] ? trace_hardirqs_off+0xd/0xf [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31 [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81035751>] ? process_one_work+0x11a/0x2bf [<ffffffff81055af3>] ? lock_acquired+0x1d0/0x1df [<ffffffffa00410f3>] ? hci_acl_disconn+0x65/0x65 [bluetooth] [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff810407ed>] ? finish_task_switch+0x45/0xc5 [<ffffffff810360aa>] ? manage_workers.isra.25+0x16a/0x16a [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 [<ffffffff812e5db4>] ? retint_restore_args+0x13/0x13 [<ffffffff8103996e>] ? __init_kthread_worker+0x55/0x55 [<ffffffff812e7750>] ? gs_change+0x13/0x13 Signed-off-by: -
Andre Guedes authored
This function is called in process context only, so it should use GFP_KERNEL to allocate memory. Signed-off-by:
-
Andre Guedes authored
This function is called in process context only, so it should use GFP_KERNEL to allocate memory. Signed-off-by:
-
Szymon Janc authored
It is not used outside of l2cap_core.c. Also l2cap_ertm_data_rcv is only used after it is defined so there is no need for forward declaration. Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Acked-by:
-
Andrei Emeltchenko authored
Add channel-specific skb allocation method Signed-off-by:
Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by:
-
Octavian Purdila authored
Since bluetooth uses multiple protocols types, to avoid lockdep warnings, we need to use different lockdep classes (one for each protocol type). This is already done in bt_sock_create but it misses a couple of cases when new connections are created. This patch corrects that to fix the following warning: <4>[ 1864.732366] ======================================================= <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ] <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3 <4>[ 1864.733883] ------------------------------------------------------- <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock: <4>[ 1864.734869] (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.735541] <4>[ 1864.735549] but task is already holding lock: <4>[ 1864.736045] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc <4>[ 1864.736732] <4>[ 1864.736740] which lock already depends on the new lock. <4>[ 1864.736750] <4>[ 1864.737428] <4>[ 1864.737437] the existing dependency chain (in reverse order) is: <4>[ 1864.738016] <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}: <4>[ 1864.738549] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.738977] [<c13d35c1>] lock_sock_nested+0x58/0x68 <4>[ 1864.739411] [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76 <4>[ 1864.739858] [<c13d06c3>] __sock_sendmsg+0x50/0x59 <4>[ 1864.740279] [<c13d0ea2>] sock_sendmsg+0x94/0xa8 <4>[ 1864.740687] [<c13d0ede>] kernel_sendmsg+0x28/0x37 <4>[ 1864.741106] [<c14969ca>] rfcomm_send_frame+0x30/0x38 <4>[ 1864.741542] [<c1496a2a>] rfcomm_send_ua+0x58/0x5a <4>[ 1864.741959] [<c1498447>] rfcomm_run+0x441/0xb52 <4>[ 1864.742365] [<c104f095>] kthread+0x63/0x68 <4>[ 1864.742742] [<c14d5182>] kernel_thread_helper+0x6/0xd <4>[ 1864.743187] <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}: <4>[ 1864.743667] [<c1061ada>] __lock_acquire+0x988/0xc00 <4>[ 1864.744100] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.744519] [<c14d2c70>] __mutex_lock_common+0x3b/0x33f <4>[ 1864.744975] [<c14d303e>] mutex_lock_nested+0x2d/0x36 <4>[ 1864.745412] [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.745842] [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b <4>[ 1864.746288] [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62 <4>[ 1864.746737] [<c13d275d>] sys_socketcall+0x1db/0x422 <4>[ 1864.747165] [<c14d42f0>] syscall_call+0x7/0xb Signed-off-by: -
Andrei Emeltchenko authored
Signed-off-by:
-
Johan Hedberg authored
It's a very common test to see if both the local and the remote device have SSP enabled. By creating a simple function to test this we can shorten many if-statements in the code. Signed-off-by:
-
Johan Hedberg authored
The ssp_mode is essentially just a boolean so it's more appropriate to have it simply as a flag in hdev->dev_flags. Signed-off-by:
-
Johan Hedberg authored
Now that the flags member of struct hci_conn is supposed to accommodate any boolean type values we can easily merge all boolean members into it. Signed-off-by:
-
Johan Hedberg authored
This patch updates mgmt_ev_device_connected and mgmt_ev_device found to include an EIR-encoded remote name and class whenever possible. With this addition the mgmt_ev_remote_name event becomes unnecessary and can be removed. Since the connected event doesn't map to hci_conn_complete anymore a HCI_CONN_MGMT_CONNECTED flag is added to track when mgmt has been notified about a connection. Signed-off-by:
-
Johan Hedberg authored
The hdev->out variable is essentially a boolean so the type 'bool' makes more sense than u8. Signed-off-by:
-
Johan Hedberg authored
These flags can and will be used for more general purpose values than just pending state transitions so the more common name "flags" makes more sense than "pend". Signed-off-by:
-
Johan Hedberg authored
There's no need to have a separate device class field since the same information can be encoded into the EIR data. Signed-off-by:
-
Johan Hedberg authored
This makes the function accessible from all places it's needed (e.g. mgmt.c and hci_event.c). Signed-off-by:
-
Johan Hedberg authored
This patch adds missing EIR defines (as specified in the Bluetooth Assigned Numbers document) to hci.h. Signed-off-by:
-
Johan Hedberg authored
This allows for other uses such as checking for an embedded class of device value in order to decide whether to append the class or not. Signed-off-by:
-
Johan Hedberg authored
This patch add a two byte eir_len parameter mgmt_ev_device_found. Since it's unlikely that the data will in the short term be much bigger than conventional EIR lengths just use a small stack based buffer for now to avoid dynamic memory allocation & freeing. Signed-off-by:
-
Johan Hedberg authored
User space uses device_(dis)connected instead of just (dis)connected so rename the defines and functions to match this. Signed-off-by:
-
Johan Hedberg authored
There are several other dev_flags besided HCI_MGMT that should not be cleared upon reset. Signed-off-by:
-
Andre Guedes authored
Devices found during LE scan should be reported to userspace through mgmt_device_found events. Signed-off-by:
-
Andre Guedes authored
This patch adds a new parameter to mgmt_device_found() to inform the length of 'eir' pointer. EIR data from LE advertising report event doesn't have a fixed length as EIR data from extended inquiry result event does. We needed to change mgmt_device_found() so it copies 'eir_len' bytes instead of HCI_MAX_EIR_LENGTH. Signed-off-by:
-
Andrei Emeltchenko authored
Signed-off-by:
-
Andrei Emeltchenko authored
Remove unneeded conversion from sk to chan. Signed-off-by:
-
Szymon Janc authored
Reference counter was incremented when starting ack timer but decremented only when clearing timer, not when timer fired. Signed-off-by:
-
Szymon Janc authored
There is no need to send RNR immediately when entring local busy. Also upper layer might clear local busy condition before ack timer expires saving few cycles for sending RNR. This also prevents sending two RNRs in some cases where sending one would be enough i.e received N I-frame can trigger local busy (sending RNR acking up to N-1 I-frame) and later sending ack (RNR acking up to N I-frame). This was affecting TC_ERM_BV_07_C and TC_ERM_BV_22_C with some non default channel parameters (tx window and receiving buffer sizes). Signed-off-by:
-
Szymon Janc authored
ack_timer should be cleared when sending ACK to avoid acking I-frames twice. This commit introduces helper function (only send ack, not clearing timer) which is used by l2cap_send_ack and l2cap_ack_timeout. This is to avoid clearing ack timer in timer function. Signed-off-by:
-
Szymon Janc authored
SREJ frame with P-bit set acknowledges I-frames numbered up to (ReqSeq - 1). With this patch P-bit in SREJ is set only when there are some I-frames to ack. This fixes ambiguous situation when lost of I-frame with TxSeq=0 would result in sending SREJ acking all previous I-frames. Consider following scenario: TxWindow=3 HostA: sent I-frame TxSeq=0 HostA: sent I-frame TxSeq=1 HostA: sent I-frame TxSeq=2 HostB: missed I-frame TxSeq=0 HostB: received I-frame TxSeq=1 HostB: sent SREJ ReqSeq=0 Pbit=1 HostA: received SREJ ReqSeq=0 Pbit=1 <- All I-frames acked or not? ... Signed-off-by:
-
Szymon Janc authored
This is usefull when need to make action after timer was cleared depending on if it was running or not. Signed-off-by:
-
