summaryrefslogtreecommitdiffstats
path: root/net/bluetooth (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Fix hci_conn reference counting for auto-connectionsJohan Hedberg2014-08-203-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | Recently the LE passive scanning and auto-connections feature was introduced. It uses the hci_connect_le() API which returns a hci_conn along with a reference count to that object. All previous users would tie this returned reference to some existing object, such as an L2CAP channel, and there'd be no leaked references this way. For auto-connections however the reference was returned but not stored anywhere, leaving established connections with one higher reference count than they should have. Instead of playing special tricks with hci_conn_hold/drop this patch associates the returned reference from hci_connect_le() with the object that in practice does own this reference, i.e. the hci_conn_params struct that caused us to initiate a connection in the first place. Once the connection is established or fails to establish this reference is removed appropriately. One extra thing needed is to call hci_pend_le_actions_clear() before calling hci_conn_hash_flush() so that the reference is cleared before the hci_conn objects are fully removed. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds2014-08-0622-1570/+3620
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull networking updates from David Miller: "Highlights: 1) Steady transitioning of the BPF instructure to a generic spot so all kernel subsystems can make use of it, from Alexei Starovoitov. 2) SFC driver supports busy polling, from Alexandre Rames. 3) Take advantage of hash table in UDP multicast delivery, from David Held. 4) Lighten locking, in particular by getting rid of the LRU lists, in inet frag handling. From Florian Westphal. 5) Add support for various RFC6458 control messages in SCTP, from Geir Ola Vaagland. 6) Allow to filter bridge forwarding database dumps by device, from Jamal Hadi Salim. 7) virtio-net also now supports busy polling, from Jason Wang. 8) Some low level optimization tweaks in pktgen from Jesper Dangaard Brouer. 9) Add support for ipv6 address generation modes, so that userland can have some input into the process. From Jiri Pirko. 10) Consolidate common TCP connection request code in ipv4 and ipv6, from Octavian Purdila. 11) New ARP packet logger in netfilter, from Pablo Neira Ayuso. 12) Generic resizable RCU hash table, with intial users in netlink and nftables. From Thomas Graf. 13) Maintain a name assignment type so that userspace can see where a network device name came from (enumerated by kernel, assigned explicitly by userspace, etc.) From Tom Gundersen. 14) Automatic flow label generation on transmit in ipv6, from Tom Herbert. 15) New packet timestamping facilities from Willem de Bruijn, meant to assist in measuring latencies going into/out-of the packet scheduler, latency from TCP data transmission to ACK, etc" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1536 commits) cxgb4 : Disable recursive mailbox commands when enabling vi net: reduce USB network driver config options. tg3: Modify tg3_tso_bug() to handle multiple TX rings amd-xgbe: Perform phy connect/disconnect at dev open/stop amd-xgbe: Use dma_set_mask_and_coherent to set DMA mask net: sun4i-emac: fix memory leak on bad packet sctp: fix possible seqlock seadlock in sctp_packet_transmit() Revert "net: phy: Set the driver when registering an MDIO bus device" cxgb4vf: Turn off SGE RX/TX Callback Timers and interrupts in PCI shutdown routine team: Simplify return path of team_newlink bridge: Update outdated comment on promiscuous mode net-timestamp: ACK timestamp for bytestreams net-timestamp: TCP timestamping net-timestamp: SCHED timestamp on entering packet scheduler net-timestamp: add key to disambiguate concurrent datagrams net-timestamp: move timestamp flags out of sk_flags net-timestamp: extend SCM_TIMESTAMPING ancillary data struct cxgb4i : Move stray CPL definitions to cxgb4 driver tcp: reduce spurious retransmits due to transient SACK reneging qlcnic: Initialize dcbnl_ops before register_netdev ...
| * Merge tag 'master-2014-07-31' of ↵David S. Miller2014-08-056-47/+287
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next Conflicts: net/6lowpan/iphc.c Minor conflicts in iphc.c were changes overlapping with some style cleanups. John W. Linville says: ==================== Please pull this last(?) batch of wireless change intended for the 3.17 stream... For the NFC bits, Samuel says: "This is a rather quiet one, we have: - A new driver from ST Microelectronics for their NCI ST21NFCB, including device tree support. - p2p support for the ST21NFCA driver - A few fixes an enhancements for the NFC digital laye" For the Atheros bits, Kalle says: "Michal and Janusz did some important RX aggregation fixes, basically we were missing RX reordering altogether. The 10.1 firmware doesn't support Ad-Hoc mode and Michal fixed ath10k so that it doesn't advertise Ad-Hoc support with that firmware. Also he implemented a workaround for a KVM issue." For the Bluetooth bits, Gustavo and Johan say: "To quote Gustavo from his previous request: 'Some last minute fixes for -next. We have a fix for a use after free in RFCOMM, another fix to an issue with ADV_DIRECT_IND and one for ADV_IND with auto-connection handling. Last, we added support for reading the codec and MWS setting for controllers that support these features.' Additionally there are fixes to LE scanning, an update to conform to the 4.1 core specification as well as fixes for tracking the page scan state. All of these fixes are important for 3.17." And, "We've got: - 6lowpan fixes/cleanups - A couple crash fixes, one for the Marvell HCI driver and another in LE SMP. - Fix for an incorrect connected state check - Fix for the bondable requirement during pairing (an issue which had crept in because of using "pairable" when in fact the actual meaning was "bondable" (these have different meanings in Bluetooth)" Along with those are some late-breaking hardware support patches in brcmfmac and b43 as well as a stray ath9k patch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| | * Bluetooth: Always use non-bonding requirement when not bondableJohan Hedberg2014-07-301-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | When we're not bondable we should never send any other SSP authentication requirement besides one of the non-bonding ones. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Rename pairable mgmt setting to bondableJohan Hedberg2014-07-301-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | This setting maps to the HCI_BONDABLE flag which tracks whether we're bondable or not. Therefore, rename the mgmt setting and respective command accordingly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Rename HCI_PAIRABLE to HCI_BONDABLEJohan Hedberg2014-07-304-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | The HCI_PAIRABLE flag isn't actually controlling whether we're pairable but whether we're bondable. Therefore, rename it accordingly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix sparse warning from HID new leds handlingMarcel Holtmann2014-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new leds bit handling produces this spares warning. CHECK net/bluetooth/hidp/core.c net/bluetooth/hidp/core.c:156:60: warning: dubious: x | !y Just fix it by doing an explicit x << 0 shift operation. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Fix check for connected state when pairingJohan Hedberg2014-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Both BT_CONNECTED and BT_CONFIG state mean that we have a baseband link available. We should therefore check for either of these when pairing and deciding whether to call hci_conn_security() directly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix SMP context tracking leading to a kernel crashJohan Hedberg2014-07-301-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HCI_CONN_LE_SMP_PEND flag is supposed to indicate whether we have an SMP context or not. If the context creation fails, or some other error is indicated between setting the flag and creating the context the flag must be cleared first. This patch ensures that smp_chan_create() clears the flag in case of allocation failure as well as reorders code in smp_cmd_security_req() that could lead to returning an error between setting the flag and creating the context. Without the patch the following kind of kernel crash could be observed (this one because of unacceptable authentication requirements in a Security Request): [ +0.000855] kernel BUG at net/bluetooth/smp.c:606! [ +0.000000] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ +0.000000] CPU: 0 PID: 58 Comm: kworker/u5:2 Tainted: G W 3.16.0-rc1+ #785 [ +0.008391] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ +0.000000] Workqueue: hci0 hci_rx_work [ +0.000000] task: f4dc8f90 ti: f4ef0000 task.ti: f4ef0000 [ +0.000000] EIP: 0060:[<c13432b6>] EFLAGS: 00010246 CPU: 0 [ +0.000000] EIP is at smp_chan_destroy+0x1e/0x145 [ +0.000709] EAX: f46db870 EBX: 00000000 ECX: 00000000 EDX: 00000005 [ +0.000000] ESI: f46db870 EDI: f46db870 EBP: f4ef1dc0 ESP: f4ef1db0 [ +0.000000] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ +0.000000] CR0: 8005003b CR2: b666b0b0 CR3: 00022000 CR4: 00000690 [ +0.000000] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ +0.000000] DR6: fffe0ff0 DR7: 00000400 [ +0.000000] Stack: [ +0.000000] 00000005 f17b7840 f46db870 f4ef1dd4 f4ef1de4 c1343441 c134342e 00000000 [ +0.000000] c1343441 00000005 00000002 00000000 f17b7840 f4ef1e38 c134452a 00002aae [ +0.000000] 01ef1e00 00002aae f46bd980 f46db870 00000039 ffffffff 00000007 f4ef1e34 [ +0.000000] Call Trace: [ +0.000000] [<c1343441>] smp_failure+0x64/0x6c [ +0.000000] [<c134342e>] ? smp_failure+0x51/0x6c [ +0.000000] [<c1343441>] ? smp_failure+0x64/0x6c [ +0.000000] [<c134452a>] smp_sig_channel+0xad6/0xafc [ +0.000000] [<c1053b61>] ? vprintk_emit+0x343/0x366 [ +0.000000] [<c133f34e>] l2cap_recv_frame+0x1337/0x1ac4 [ +0.000000] [<c133f34e>] ? l2cap_recv_frame+0x1337/0x1ac4 [ +0.000000] [<c1172307>] ? __dynamic_pr_debug+0x3e/0x40 [ +0.000000] [<c11702a1>] ? debug_smp_processor_id+0x12/0x14 [ +0.000000] [<c1340bc9>] l2cap_recv_acldata+0xe8/0x239 [ +0.000000] [<c1340bc9>] ? l2cap_recv_acldata+0xe8/0x239 [ +0.000000] [<c1169931>] ? __const_udelay+0x1a/0x1c [ +0.000000] [<c131f120>] hci_rx_work+0x1a1/0x286 [ +0.000000] [<c137244e>] ? mutex_unlock+0x8/0xa [ +0.000000] [<c131f120>] ? hci_rx_work+0x1a1/0x286 [ +0.000000] [<c1038fe5>] process_one_work+0x128/0x1df [ +0.000000] [<c1038fe5>] ? process_one_work+0x128/0x1df [ +0.000000] [<c10392df>] worker_thread+0x222/0x2de [ +0.000000] [<c10390bd>] ? process_scheduled_works+0x21/0x21 [ +0.000000] [<c103d34c>] kthread+0x82/0x87 [ +0.000000] [<c1040000>] ? create_new_namespaces+0x90/0x105 [ +0.000000] [<c13738e1>] ret_from_kernel_thread+0x21/0x30 [ +0.000000] [<c103d2ca>] ? __kthread_parkme+0x50/0x50 [ +0.000000] Code: 65 f4 89 f0 5b 5e 5f 5d 8d 67 f8 5f c3 57 8d 7c 24 08 83 e4 f8 ff 77 fc 55 89 e5 57 89 c7 56 53 52 8b 98 e0 00 00 00 85 db 75 02 <0f> 0b 8b b3 80 00 00 00 8b 00 c1 ee 03 83 e6 01 89 f2 e8 ef 09 [ +0.000000] EIP: [<c13432b6>] smp_chan_destroy+0x1e/0x145 SS:ESP 0068:f4ef1db0 Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix incorrectly disabling page scan when toggling connectableJohan Hedberg2014-07-281-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | If we have entries in the whitelist we shouldn't disable page scanning when disabling connectable mode. This patch adds the necessary check to the Set Connectable command handler. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix clearing HCI_PSCAN flagJohan Hedberg2014-07-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a typo in the hci_cc_write_scan_enable() function where we want to clear the HCI_PSCAN flag if the SCAN_PAGE bit of the HCI command parameter was not set. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Set Simultaneous LE and BR/EDR controller option to zeroMarcel Holtmann2014-07-272-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | With the Bluetooth 4.1 specification the Simultaneous LE and BR/EDR controller option has been deprecated. It shall be set to zero and ignored otherwise. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Expose default LE advertising interval via debugfsGeorg Lukas2014-07-261-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | Expose the default values for minimum and maximum LE advertising interval via debugfs for testing purposes. Signed-off-by: Georg Lukas <georg@op-co.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Provide defaults for LE advertising intervalGeorg Lukas2014-07-262-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Store the default values for minimum and maximum advertising interval with all the other controller defaults. These vaules are sent to the adapter whenever advertising is (re)enabled. Signed-off-by: Georg Lukas <georg@op-co.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix white list handling with resolvable private addressesMarcel Holtmann2014-07-262-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devices using resolvable private addresses are required to provide an identity resolving key. These devices can not be found using the current controller white list support. This means if the kernel knows about any devices with an identity resolving key, the white list filtering must be disabled. However so far the kernel kept identity resolving keys around even for devices that are not using resolvable private addresses. The notification to userspace clearly hints to not store the key and so it is best to just remove the key from the kernel as well at that point. With this it easy now to detect when using the white list is possible or when kernel side resolving of addresses is required. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Add support for using controller white list filteringMarcel Holtmann2014-07-261-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Bluetooth controller can use a white list filter when scanning to avoid waking up the host for devices that are of no interest. Devices marked as reporting, direct connection (incoming) or general connection are now added to the controller white list. The update of the white list happens just before enabling passive scanning. In case the white list is full and can not hold all devices, the white list is not used and the filter policy set to accept all advertisements. Using the white list for scanning allows for power saving with controllers that do not handle the duplicate filtering correctly. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Fix issue with ADV_IND reports and auto-connection handlingMarcel Holtmann2014-07-233-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding remote devices to the kernel using the Add Device management command, these devices are explicitly allowed to connect. This kind of incoming connections are possible even when the controller itself is not connectable. For BR/EDR this distinction is pretty simple since there is only one type of incoming connections. With LE this is not that simple anymore since there are ADV_IND and ADV_DIRECT_IND advertising events. The ADV_DIRECT_IND advertising events are send for incoming (slave initiated) connections only. And this is the only thing the kernel should allow when adding devices using action 0x01. This meaning of incoming connections is coming from BR/EDR and needs to be mapped to LE the same way. Supporting the auto-connection of devices using ADV_IND advertising events is an important feature as well. However it does not map to incoming connections. So introduce a new action 0x02 that allows the kernel to connect to devices using ADV_DIRECT_IND and in addition ADV_IND advertising reports. This difference is represented by the new HCI_AUTO_CONN_DIRECT value for only connecting to ADV_DIRECT_IND. For connection to ADV_IND and ADV_DIRECT_IND the old value HCI_AUTO_CONN_ALWAYS is used. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Ignore ADV_DIRECT_IND attempts from unknown devicesMarcel Holtmann2014-07-231-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unconditionally connecting to devices sending ADV_DIRECT_IND when the controller is in CONNECTABLE mode is a feature that is not fully working. The background scanning trigger for this has been removed, but the statement allowing it to happen in case some other part triggers is still present. So remove that code part as well to avoid unwanted connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Get MWS transport configuration of the controllerMarcel Holtmann2014-07-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | If the Bluetooth controller supports Get MWS Transport Layer Configuration command, then issue it during initialization. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Read list of local codecs supported by the controllerMarcel Holtmann2014-07-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the Bluetooth controller supports Read Local Supported Codecs command, then issue it during initialization so that the list of codecs is known. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Avoid use of session socket after the session gets freedVignesh Raman2014-07-221-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commits 08c30aca9e698faddebd34f81e1196295f9dc063 "Bluetooth: Remove RFCOMM session refcnt" and 8ff52f7d04d9cc31f1e81dcf9a2ba6335ed34905 "Bluetooth: Return RFCOMM session ptrs to avoid freed session" allow rfcomm_recv_ua and rfcomm_session_close to delete the session (and free the corresponding socket) and propagate NULL session pointer to the upper callers. Additional fix is required to terminate the loop in rfcomm_process_rx function to avoid use of freed 'sk' memory. The issue is only reproducible with kernel option CONFIG_PAGE_POISONING enabled making freed memory being changed and filled up with fixed char value used to unmask use-after-free issues. Signed-off-by: Vignesh Raman <Vignesh_Raman@mentor.com> Signed-off-by: Vitaly Kuzmichev <Vitaly_Kuzmichev@mentor.com> Acked-by: Dean Jenkins <Dean_Jenkins@mentor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
| * | Merge tag 'master-2014-07-25' of ↵David S. Miller2014-07-2914-351/+403
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next John W. Linville says: ==================== pull request: wireless-next 2014-07-25 Please pull this batch of updates intended for the 3.17 stream! For the mac80211 bits, Johannes says: "We have a lot of TDLS patches, among them a fix that should make hwsim tests happy again. The rest, this time, is mostly small fixes." For the Bluetooth bits, Gustavo says: "Some more patches for 3.17. The most important change here is the move of the 6lowpan code to net/6lowpan. It has been agreed with Davem that this change will go through the bluetooth tree. The rest are mostly clean up and fixes." and, "Here follows some more patches for 3.17. These are mostly fixes to what we've sent to you before for next merge window." For the iwlwifi bits, Emmanuel says: "I have the usual amount of BT Coex stuff. Arik continues to work on TDLS and Ariej contributes a few things for HS2.0. I added a few more things to the firmware debugging infrastructure. Eran fixes a small bug - pretty normal content." And for the Atheros bits, Kalle says: "For ath6kl me and Jessica added support for ar6004 hw3.0, our latest version of ar6004. For ath10k Janusz added a printout so that it's easier to check what ath10k kconfig options are enabled. He also added a debugfs file to configure maximum amsdu and ampdu values. Also we had few fixes as usual." On top of that is the usual large batch of various driver updates -- brcmfmac, mwifiex, the TI drivers, and wil6210 all get some action. Rafał has also been very busy with b43 and related updates. Also, I pulled the wireless tree into this in order to resolve a merge conflict... P.S. The change to fs/compat_ioctl.c reflects a name change in a Bluetooth header file... ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| | * Bluetooth: Prefer sizeof(*ptr) when allocating memoryJohan Hedberg2014-07-213-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's safer practice to use sizeof(*ptr) instead of sizeof(ptr_type) when allocating memory in case the type changes. This also fixes the following style of warnings from static analyzers: CHECK: Prefer kzalloc(sizeof(*ie)...) over kzalloc(sizeof(struct inquiry_entry)...) + ie = kzalloc(sizeof(struct inquiry_entry), GFP_KERNEL); Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Remove unneeded variable assignment in hmac_sha256Marcel Holtmann2014-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The variable ret does not need to be assigned when declaring it. So remove this initial assignment. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Disable HCI_CONNECTABLE based passive scanning for nowJohan Hedberg2014-07-201-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When HCI_CONNECTABLE is set the code has been enabling passive scanning in order to be consistent with BR/EDR and accept connections from any device doing directed advertising to us. However, some hardware (particularly CSR) can get very noisy even when doing duplicates filtering, making this feature waste resources. Considering that the feature is for fairly corner-case use (devices who'd use directed advertising would likely be in the whitelist anyway) it's better to disable it for now. It may still be brought back later, possibly with a better implementation (e.g. through improved scan parameters). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Use EOPNOTSUPP instead of ENOTSUPPJohan Hedberg2014-07-184-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EOPNOTSUPP and ENOTSUPP errors are very similar in meaning, but ENOTSUPP is a fairly new addition to POSIX. Not all libc versions know about the value the kernel uses for ENOTSUPP so it's better to use EOPNOTSUPP to ensure understandable error messages. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix allowing initiating pairing when not pairableJohan Hedberg2014-07-171-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we're not pairable we should still allow us to act as initiators for pairing, i.e. the HCI_PAIRABLE flag should only be affecting incoming pairing attempts. This patch fixes the relevant checks for the hci_io_capa_request_evt() and hci_pin_code_request_evt() functions. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Introduce a flag to track who really initiates authenticationJohan Hedberg2014-07-172-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though our side requests authentication, the original action that caused it may be remotely triggered, such as an incoming L2CAP or RFCOMM connect request. To track this information introduce a new hci_conn flag called HCI_CONN_AUTH_INITIATOR. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Pass initiator/acceptor information to hci_conn_security()Johan Hedberg2014-07-175-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're interested in whether an authentication request is because of a remote or local action. So far hci_conn_security() has been used both for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect requests) so without some modifications it cannot know which peer is responsible for requesting authentication. This patch adds a new "bool initiator" parameter to hci_conn_security() to indicate which side is responsible for the request and updates the current users to pass this information correspondingly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix resetting remote authentication requirement after pairingJohan Hedberg2014-07-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a new hci_conn object is created the remote SSP authentication requirement is set to the invalid value 0xff to indicate that it is unknown. Once pairing completes however the code was leaving it as-is. In case a new pairing happens over the same connection it is important that we reset the value back to unknown so that the pairing code doesn't make false assumptions about the requirements. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: never linger on process exitVladimir Davydov2014-07-173-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the current process is exiting, lingering on socket close will make it unkillable, so we should avoid it. Reproducer: #include <sys/types.h> #include <sys/socket.h> #define BTPROTO_L2CAP 0 #define BTPROTO_SCO 2 #define BTPROTO_RFCOMM 3 int main() { int fd; struct linger ling; fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); //or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP); //or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); ling.l_onoff = 1; ling.l_linger = 1000000000; setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling)); return 0; } Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
| | * Bluetooth: Don't bother user space without IO capabilitiesJohan Hedberg2014-07-172-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If user space has a NoInputNoOutput IO capability it makes no sense to bother it with confirmation requests. This patch updates both SSP and SMP to check for the local IO capability before sending a user confirmation request to user space. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix using uninitialized variable when pairingJohan Hedberg2014-07-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6c53823ae0e10e723131055e1e65dd6a328a228e reshuffled the way the authentication requirement gets set in the hci_io_capa_request_evt() function, but at the same time it failed to update an if-statement where cp.authentication is used before it has been initialized. The correct value the code should be looking for in this if-statement is conn->auth_type. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.16
| | * Bluetooth: Fix always checking the blacklist for incoming connectionsJohan Hedberg2014-07-161-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | We should check the blacklist no matter what, meaning also when we're not connectable. This patch fixes the respective logic in the function making the decision whether to accept a connection or not. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix trying to initiate connections when acting as LE slaveJohan Hedberg2014-07-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we have at least one LE slave connection most (probably all) controllers will refuse to initiate any new connections. To avoid unnecessary failures simply check for this situation up-front and skip the connection attempt. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Add a role parameter to hci_conn_add()Johan Hedberg2014-07-163-21/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to be able to track slave vs master LE connections in hci_conn_hash, and to be able to do that we need to know the role of the connection by the time hci_conn_add_has() is called. This means in practice the hci_conn_add() call that creates the hci_conn_object. This patch adds a new role parameter to hci_conn_add() function to give the object its initial role value, and updates the callers to pass the appropriate role to it. Since the function now takes care of initializing both conn->role and conn->out values we can remove some other unnecessary assignments. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Use explicit role instead of a bool in function parametersJohan Hedberg2014-07-166-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To make the code more understandable it makes sense to use the new HCI defines for connection role instead of a "bool master" parameter. This makes it immediately clear when looking at the function calls what the last parameter is describing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Convert HCI_CONN_MASTER flag to a conn->role variableJohan Hedberg2014-07-164-33/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | Having a dedicated u8 role variable in the hci_conn struct greatly simplifies tracking of the role, since this is the native way that it's represented on the HCI level. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Add proper defines for HCI connection roleJohan Hedberg2014-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All HCI commands and events, including LE ones, use 0x00 for master role and 0x01 for slave role. It makes therefore sense to add generic defines for these instead of the current LE_CONN_ROLE_MASTER. Having clean defines will also make it possible to provide simpler internal APIs. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Don't try to reject failed LE connectionsJohan Hedberg2014-07-151-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | The check for the blacklist in hci_le_conn_complete_evt() should be when we know that we have an actual successful connection (ev->status being non-zero). This patch fixes this ordering. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Remove unnecessary params variable from process_adv_report()Johan Hedberg2014-07-151-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The params variable was just used for storing the return value from the hci_pend_le_action_lookup() function and then checking whether it's NULL or not. We can simplify the code by checking the return value directly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: cmtp: Remove unnecessary null testHimangi Saraogi2014-07-141-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the null test on ctrl. ctrl is initialized at the beginning of the function to &session->ctrl. Since session is dereferenced prior to the null test, session must be a valid pointer, and &session->ctrl cannot be null. The following Coccinelle script is used for detecting the change: @r@ expression e,f; identifier g,y; statement S1,S2; @@ *e = &f->g <+... f->y ...+> *if (e != NULL || ...) S1 else S2 Signed-off-by: Himangi Saraogi <himangi774@gmail.com> Acked-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Fix trying LTK re-encryption when we don't have an LTKJohan Hedberg2014-07-141-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case that the key distribution bits cause us not to generate a local LTK we should not try to re-encrypt if we're currently encrypted with an STK. This patch fixes the check for this in the smp_sufficient_security function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * Bluetooth: Remove sco_chan_get helper functionMarcel Holtmann2014-07-141-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | The sco_chan_get helper function is only used in two places and really only protects conn->sk with a lock. So instead of hiding that fact, just put the actual code in place where it is used. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Convert L2CAP ident spinlock into a mutexMarcel Holtmann2014-07-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The spinlock protecting the L2CAP ident number can be converted into a mutex since the whole processing is run in a workqueue. So instead of using a spinlock, just use a mutex here. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Remove unneeded forward declaration of sco_chan_delMarcel Holtmann2014-07-131-29/+27
| | | | | | | | | | | | | | | | | | | | | | | | The forward declaration of sco_chan_del is not needed and thus just remove it. Move sco_chan_del into the proper location. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Remove unneeded forward declaration of __sco_chan_addMarcel Holtmann2014-07-131-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | The forward declaration of __sco_chan_add is not needed and thus just remove it. Move __sco_chan_add into the proper location. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Allocate struct inquiry_entry with GFP_KERNELMarcel Holtmann2014-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The allocation of inquiry cache entries is triggered as a result of processing HCI events. Since the processing is done in the context of a workqueue, there is no needed to allocate with GFP_ATOMIC in that case. Switch it to GFP_KERNEL. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Enable LE Long Term Key Request event only when supportedMarcel Holtmann2014-07-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The support for LE encryption is optional and with that also the LE Long Term Key Request event. If encryption is not supported, then do not bother enabling this event. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * Bluetooth: Enable LE encryption events only when supportedMarcel Holtmann2014-07-131-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The support for LE encryption is optional. When encryption is not supported then also do not enable the encryption related events. This moves the event mask setting to the third initialization stage to ensure that the LE features are available. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>