An error occurred fetching the project authors.
- 13 Feb, 2012 25 commits
-
-
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 <andre.guedes@openbossa.org> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Reviewed-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
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: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Johan Hedberg authored
This patch makes sure that devices with stronger signal (RSSI closer to 0) are sorted first in the resolve list and will therefore get their names resolved first during device discovery. Since it's more likely that the device the user is trying to discover has a strong signal due to its proximity this ensures that the user gets the "device found" event for it more quickly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
David Herrmann authored
Since we remove the owner field of hci_dev hci_dev_put and __hci_dev_put do the same so we can merge them into one function. Same for hci_dev_hold and __hci_dev_hold. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
David Herrmann authored
The hci_dev->dev device structure has an internal refcount. This refcount is used to protect the whole hci_dev object. However, we currently do not use it. Therefore, if someone calls hci_free_dev() we currently immediately destroy the hci_dev object because we never took the device refcount. This even happens if the hci_dev->refcnt is not 0. In fact, the hci_dev->refcnt is totally useless in its current state. Therefore, we simply remove hci_dev->refcnt and instead use hci_dev->dev refcnt. This fixes all the symptoms and also correctly integrates the device structure into our bluetooth bus system. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
David Herrmann authored
After unregistering an hci_dev object a bluetooth driver does not have any callbacks in the hci_dev structure left over. Therefore, there is no need to keep a reference to the module. Previously, we needed this to protect the hci-destruct callback. However, this callback is no longer available so we do not need this owner field, anymore. Drivers now call hci_unregister_dev() and they are done with the object. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
David Herrmann authored
The hci-destruct callback is not used by any driver so we can remove it. There is no reason to keep it alive, anymore. Drivers can free their internal data on driver-release and we do not need to provide a public destruct callback. Internally, we still use a destruct callback inside of hci_sysfs.c. This one is used to correctly free our hci_dev data structure if no more users have a reference to it. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
David Herrmann authored
Several drivers already provide an empty callback so we can actually make this optional and then remove all those empty callbacks in the drivers. This callback isn't needed at all by most drivers as they can remove their allocated structures on device disconnect and not on hci destruction. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Vinicius Costa Gomes authored
queue_delayed_work() expects a relative time for when that work should be scheduled. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Johan Hedberg authored
This patch adds the necessary logic to perform name lookups after inquiry completes. This is done by checking for entries in the resolve list after each inquiry complete and remote name complete HCI event. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This patch adds proper state tracking to the device discovery process. This makes it possible to return appropriate errors when trying to stop a non-active discovery or start discovery when it is already ongoing. Once name resolving is implemented this also makes it possible to know what the right action to do is when a remote name lookup is cancelled. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This struct is used for not just inquiry caching but also for general device discovery state tracking so it's better to rename it to something more appropriate. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
If user-space has already confirmed the name for a remote device we shouldn't request confirmation again. The simplest way to do this is to return the name state from hci_inquiry_cache_update (if it is anything else than unknown then we do not need confirmation from user-space). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This patch adds initial support for mgmt_confirm_name. It adds the necessary tracking of the name state by extending the inquiry cache. The actual name resolving operation (to be done once inquiry is finished) is not yet part of this patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This makes it possible to use the convenience functions provided for standard kernel list types and it also makes it easier to extend the use of the cache for the management interface where e.g. name resolving control will be needed. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
-
- 03 Jan, 2012 1 commit
-
-
Andre Guedes authored
This patch renames hdev->extfeatures to hdev->host_features since it holds the extended features Page 1 (aka host features). Signed-off-by: Andre Guedes <aguedespe@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
- 22 Dec, 2011 4 commits
-
-
Gustavo F. Padovan authored
They don't need to disable interrupts anymore, we only run in process context now. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
It was never used, so removing it. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Brian Gix authored
To achive Man-In-The-Middle (MITM) level security with Low Energy, we have to enable User Passkey Comparison. This commit modifies the hard-coded JUST-WORKS pairing mechanism to support query via the MGMT interface of Passkey comparison and User Confirmation. Signed-off-by: Brian Gix <bgix@codeaurora.org> Acked-by: Marcel Holtmann<marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Ulisses Furquim authored
The struct hci_proto and all related register/unregister and dispatching code was removed. HCI core code now call directly the SCO and L2CAP event functions. Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
- 18 Dec, 2011 10 commits
-
-
Andrei Emeltchenko authored
Implement block size read function. Use different variables for packet-based and block-based flow control. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Johan Hedberg authored
We do not want the service cache to be enabled indefinitely after mgmt_read_info is called. To solve this a timer is added which will automatically disable the cache if mgmt_set_dev_class isn't called within 5 seconds of calling mgmt_read_info. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Johan Hedberg authored
Instead of having an explicit service cache command we can make the mgmt API simpler by implicitly enabling the cache when mgmt_read_info is called for the first time and disabling it when mgmt_set_dev_class is called. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
As we run in process context now we don't need worqueue to add e del from sysfs. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
This should simplify Bluetooth core processing a lot. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
As part of the moving on all the Bluetooth processing to Process context. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
Handling hci_conn_hash with RCU make us avoid some locking and disable tasklets. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
As HCI rx path is now done in process context it makes sense to do all the timer in process context as well. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
Bluetooth rx task runs now in a workqueue, so it a good approach run any timer that share locking with process context code also in a workqueue. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-
Gustavo F. Padovan authored
Now we run everything in HCI in process context, so it's a better idea use mutex instead spin_lock. The macro remains hci_dev_lock() (and I got rid of hci_dev_lock_bh()), of course. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
-