aboutsummaryrefslogtreecommitdiff
path: root/net/bluetooth
AgeCommit message (Collapse)Author
2013-12-08net: rework recvmsg handler msg_name and msg_namelen logicHannes Frederic Sowa
[ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ] 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-13Bluetooth: Fix rfkill functionality during the HCI setup stageJohan Hedberg
commit bf5430360ebe4b2d0c51d91f782e649107b502eb upstream. We need to let the setup stage complete cleanly even when the HCI device is rfkilled. Otherwise the HCI device will stay in an undefined state and never get notified to user space through mgmt (even when it gets unblocked through rfkill). This patch makes sure that hci_dev_open() can be called in the HCI_SETUP stage, that blocking the device doesn't abort the setup stage, and that the device gets proper powered down as soon as the setup stage completes in case it was blocked meanwhile. The bug that this patch fixed can be very easily reproduced using e.g. the rfkill command line too. By running "rfkill block all" before inserting a Bluetooth dongle the resulting HCI device goes into a state where it is never announced over mgmt, not even when "rfkill unblock all" is run. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-13Bluetooth: Introduce a new HCI_RFKILLED flagJohan Hedberg
commit 5e130367d43ff22836bbae380d197d600fe8ddbb upstream. This makes it more convenient to check for rfkill (no need to check for dev->rfkill before calling rfkill_blocked()) and also avoids potential races if the RFKILL state needs to be checked from within the rfkill callback. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-13Bluetooth: Fix encryption key size for peripheral roleAndre Guedes
commit 89cbb4da0abee2f39d75f67f9fd57f7410c8b65c upstream. This patch fixes the connection encryption key size information when the host is playing the peripheral role. We should set conn->enc_key_ size in hci_le_ltk_request_evt, otherwise it is left uninitialized. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-13Bluetooth: Fix security level for peripheral roleAndre Guedes
commit f8776218e8546397be64ad2bc0ebf4748522d6e3 upstream. While playing the peripheral role, the host gets a LE Long Term Key Request Event from the controller when a connection is established with a bonded device. The host then informs the LTK which should be used for the connection. Once the link is encrypted, the host gets an Encryption Change Event. Therefore we should set conn->pending_sec_level instead of conn-> sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is properly updated in hci_encrypt_change_evt. Moreover, since we have a LTK associated to the device, we have at least BT_SECURITY_MEDIUM security level. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-13HID: fix unused rsize usageJiri Kosina
commit bc197eedef1ae082ec662c64c3f4aa302821fb7a upstream. 27ce4050 ("HID: fix data access in implement()") by mistake removed a setting of buffer size in hidp. Fix that by putting it back. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-13HID: fix data access in implement()Jiri Kosina
commit 27ce405039bfe6d3f4143415c638f56a3df77dca upstream. implement() is setting bytes in LE data stream. In case the data is not aligned to 64bits, it reads past the allocated buffer. It doesn't really change any value there (it's properly bitmasked), but in case that this read past the boundary hits a page boundary, pagefault happens when accessing 64bits of 'x' in implement(), and kernel oopses. This happens much more often when numbered reports are in use, as the initial 8bit skip in the buffer makes the whole process work on values which are not aligned to 64bits. This problem dates back to attempts in 2005 and 2006 to make implement() and extract() as generic as possible, and even back then the problem was realized by Adam Kroperlin, but falsely assumed to be impossible to cause any harm: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html I have made several attempts at fixing it "on the spot" directly in implement(), but the results were horrible; the special casing for processing last 64bit chunk and switching to different math makes it unreadable mess. I therefore took a path to allocate a few bytes more which will never make it into final report, but are there as a cushion for all the 64bit math operations happening in implement() and extract(). All callers of hid_output_report() are converted at the same time to allocate the buffer by newly introduced hid_alloc_report_buf() helper. Bruno noticed that the whole raw_size test can be dropped as well, as hid_alloc_report_buf() makes sure that the buffer is always of a proper size. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-23Bluetooth: Fix invalid length check in l2cap_information_rsp()Jaganath Kanakkassery
The length check is invalid since the length varies with type of info response. This was introduced by the commit cb3b3152b2f5939d67005cff841a1ca748b19888 Because of this, l2cap info rsp is not handled and command reject is sent. > ACL data: handle 11 flags 0x02 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x00b8 Enhanced Retransmission mode Streaming mode FCS Option Fixed Channels < ACL data: handle 11 flags 0x00 dlen 10 L2CAP(s): Command rej: reason 0 Command not understood Cc: stable@vger.kernel.org Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Chan-Yeol Park <chanyeol.park@samsung.com> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-06-13Bluetooth: Fix conditions for HCI_Delete_Stored_Link_KeyJohan Hedberg
Even though the HCI_Delete_Stored_Link_Key command is mandatory for 1.1 and later controllers some controllers do not seem to support it properly as was witnessed by one Broadcom based controller: < HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7 bdaddr 00:00:00:00:00:00 all 1 > HCI Event: Command Complete (0x0e) plen 4 Delete Stored Link Key (0x03|0x0012) ncmd 1 status 0x11 deleted 0 Error: Unsupported Feature or Parameter Value Luckily this same controller also doesn't list the command in its supported commands bit mask (counting from 0 bit 7 of octet 6): < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0 > HCI Event: Command Complete (0x0e) plen 68 Read Local Supported Commands (0x04|0x0002) ncmd 1 status 0x00 Commands: ffffffffffff1ffffffffffff30fffff3f Therefore, it makes sense to move sending of HCI_Delete_Stored_Link_Key to after receiving the supported commands response and to only send it if its respective bit in the mask is set. The downside of this is that we no longer send the HCI_Delete_Stored_Link_Key command for Bluetooth 1.1 controllers since HCI_Read_Local_Supported_Command was introduced in version 1.2, but this is an acceptable penalty as the command in question shouldn't affect critical behavior. Reported-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Tested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-06-13Bluetooth: Fix crash in l2cap_build_cmd() with small MTUAnderson Lizardo
If a too small MTU value is set with ioctl(HCISETACLMTU) or by a bogus controller, memory corruption happens due to a memcpy() call with negative length. Fix this crash on either incoming or outgoing connections with a MTU smaller than L2CAP_HDR_SIZE + L2CAP_CMD_HDR_SIZE: [ 46.885433] BUG: unable to handle kernel paging request at f56ad000 [ 46.888037] IP: [<c03d94cd>] memcpy+0x1d/0x40 [ 46.888037] *pdpt = 0000000000ac3001 *pde = 00000000373f8067 *pte = 80000000356ad060 [ 46.888037] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC [ 46.888037] Modules linked in: hci_vhci bluetooth virtio_balloon i2c_piix4 uhci_hcd usbcore usb_common [ 46.888037] CPU: 0 PID: 1044 Comm: kworker/u3:0 Not tainted 3.10.0-rc1+ #12 [ 46.888037] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 46.888037] Workqueue: hci0 hci_rx_work [bluetooth] [ 46.888037] task: f59b15b0 ti: f55c4000 task.ti: f55c4000 [ 46.888037] EIP: 0060:[<c03d94cd>] EFLAGS: 00010212 CPU: 0 [ 46.888037] EIP is at memcpy+0x1d/0x40 [ 46.888037] EAX: f56ac1c0 EBX: fffffff8 ECX: 3ffffc6e EDX: f55c5cf2 [ 46.888037] ESI: f55c6b32 EDI: f56ad000 EBP: f55c5c68 ESP: f55c5c5c [ 46.888037] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 46.888037] CR0: 8005003b CR2: f56ad000 CR3: 3557d000 CR4: 000006f0 [ 46.888037] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 46.888037] DR6: ffff0ff0 DR7: 00000400 [ 46.888037] Stack: [ 46.888037] fffffff8 00000010 00000003 f55c5cac f8c6a54c ffffffff f8c69eb2 00000000 [ 46.888037] f4783cdc f57f0070 f759c590 1001c580 00000003 0200000a 00000000 f5a88560 [ 46.888037] f5ba2600 f5a88560 00000041 00000000 f55c5d90 f8c6f4c7 00000008 f55c5cf2 [ 46.888037] Call Trace: [ 46.888037] [<f8c6a54c>] l2cap_send_cmd+0x1cc/0x230 [bluetooth] [ 46.888037] [<f8c69eb2>] ? l2cap_global_chan_by_psm+0x152/0x1a0 [bluetooth] [ 46.888037] [<f8c6f4c7>] l2cap_connect+0x3f7/0x540 [bluetooth] [ 46.888037] [<c019b37b>] ? trace_hardirqs_off+0xb/0x10 [ 46.888037] [<c01a0ff8>] ? mark_held_locks+0x68/0x110 [ 46.888037] [<c064ad20>] ? mutex_lock_nested+0x280/0x360 [ 46.888037] [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150 [ 46.888037] [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0 [ 46.888037] [<c064ad08>] ? mutex_lock_nested+0x268/0x360 [ 46.888037] [<c01a125b>] ? trace_hardirqs_on+0xb/0x10 [ 46.888037] [<f8c72f8d>] l2cap_recv_frame+0xb2d/0x1d30 [bluetooth] [ 46.888037] [<c01a0ff8>] ? mark_held_locks+0x68/0x110 [ 46.888037] [<c064b9d9>] ? __mutex_unlock_slowpath+0xa9/0x150 [ 46.888037] [<c01a118c>] ? trace_hardirqs_on_caller+0xec/0x1b0 [ 46.888037] [<f8c754f1>] l2cap_recv_acldata+0x2a1/0x320 [bluetooth] [ 46.888037] [<f8c491d8>] hci_rx_work+0x518/0x810 [bluetooth] [ 46.888037] [<f8c48df2>] ? hci_rx_work+0x132/0x810 [bluetooth] [ 46.888037] [<c0158979>] process_one_work+0x1a9/0x600 [ 46.888037] [<c01588fb>] ? process_one_work+0x12b/0x600 [ 46.888037] [<c015922e>] ? worker_thread+0x19e/0x320 [ 46.888037] [<c015922e>] ? worker_thread+0x19e/0x320 [ 46.888037] [<c0159187>] worker_thread+0xf7/0x320 [ 46.888037] [<c0159090>] ? rescuer_thread+0x290/0x290 [ 46.888037] [<c01602f8>] kthread+0xa8/0xb0 [ 46.888037] [<c0656777>] ret_from_kernel_thread+0x1b/0x28 [ 46.888037] [<c0160250>] ? flush_kthread_worker+0x120/0x120 [ 46.888037] Code: c3 90 8d 74 26 00 e8 63 fc ff ff eb e8 90 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 cb 89 c7 c1 e9 02 89 d6 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 8b 5d f4 8b 75 f8 8b 7d fc 89 [ 46.888037] EIP: [<c03d94cd>] memcpy+0x1d/0x40 SS:ESP 0068:f55c5c5c [ 46.888037] CR2: 00000000f56ad000 [ 46.888037] ---[ end trace 0217c1f4d78714a9 ]--- Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org> Cc: stable@vger.kernel.org Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-06-12Bluetooth: Fix mgmt handling of power on failuresJohan Hedberg
If hci_dev_open fails we need to ensure that the corresponding mgmt_set_powered command gets an appropriate response. This patch fixes the missing response by adding a new mgmt_set_powered_failed function that's used to indicate a power on failure to mgmt. Since a situation with the device being rfkilled may require special handling in user space the patch uses a new dedicated mgmt status code for this. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-06-12Bluetooth: Fix missing length checks for L2CAP signalling PDUsJohan Hedberg
There has been code in place to check that the L2CAP length header matches the amount of data received, but many PDU handlers have not been checking that the data received actually matches that expected by the specific PDU. This patch adds passing the length header to the specific handler functions and ensures that those functions fail cleanly in the case of an incorrect amount of data. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-06-12Bluetooth: Fix checks for LE support on LE-only controllersJohan Hedberg
LE-only controllers do not support extended features so any kind of host feature bit checks do not make sense for them. This patch fixes code used for both single-mode (LE-only) and dual-mode (BR/EDR/LE) to use the HCI_LE_ENABLED flag instead of the "Host LE supported" feature bit for LE support tests. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-01Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull VFS updates from Al Viro, Misc cleanups all over the place, mainly wrt /proc interfaces (switch create_proc_entry to proc_create(), get rid of the deprecated create_proc_read_entry() in favor of using proc_create_data() and seq_file etc). 7kloc removed. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (204 commits) don't bother with deferred freeing of fdtables proc: Move non-public stuff from linux/proc_fs.h to fs/proc/internal.h proc: Make the PROC_I() and PDE() macros internal to procfs proc: Supply a function to remove a proc entry by PDE take cgroup_open() and cpuset_open() to fs/proc/base.c ppc: Clean up scanlog ppc: Clean up rtas_flash driver somewhat hostap: proc: Use remove_proc_subtree() drm: proc: Use remove_proc_subtree() drm: proc: Use minor->index to label things, not PDE->name drm: Constify drm_proc_list[] zoran: Don't print proc_dir_entry data in debug reiserfs: Don't access the proc_dir_entry in r_open(), r_start() r_show() proc: Supply an accessor for getting the data from a PDE's parent airo: Use remove_proc_subtree() rtl8192u: Don't need to save device proc dir PDE rtl8187se: Use a dir under /proc/net/r8180/ proc: Add proc_mkdir_data() proc: Move some bits from linux/proc_fs.h to linux/{of.h,signal.h,tty.h} proc: Move PDE_NET() to fs/proc/proc_net.c ...
2013-04-29Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
2013-04-24Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
2013-04-23Bluetooth: Remove unneeded parameter from L2CAP ATT channel handlingMarcel Holtmann
The CID is fixed to L2CAP ATT channel and so there is no need to hand it down to the handling function. Just use a constant instead. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-23Bluetooth: hci_get_cmd_complete() can be staticFengguang Wu
There are new sparse warnings show up in tree: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next master head: a0b644b0385fa58ca578f6dce4473e8a8e6f6c38 commit: 75e84b7c522c6e07964cd1f5bf28535768a1e9fa Bluetooth: Add __hci_cmd_sync() helper function date: 13 days ago >> net/bluetooth/hci_core.c:82:16: sparse: symbol 'hci_get_cmd_complete' was not declared. Should it be static? Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-23Bluetooth: Fix sending write_le_host_supporte for LE-only controllersJohan Hedberg
The Bluetooth Core Specification (4.0) defines the Write LE Host Supported HCI command as only available for controllers supporting BR/EDR. This is further reflected in the Read Local Extended Features HCI command also not being available for LE-only controllers. In other words, host-side LE support is implicit for single-mode LE controllers and doesn't have explicit HCI-level enablement. This patch ensures that the LE setting is always exposed as enabled through mgmt and returns a "rejected" response if user space tries to toggle the setting. The patch also ensures that Write LE Host Supported is never sent for LE-only controllers. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-19Bluetooth: Fix HCI command send functions to use const specifierJohan Hedberg
All HCI command send functions that take a pointer to the command parameters do not need to modify the content in any way (they merely copy the data to an skb). Therefore, the parameter type should be declared const. This also allows passing already const parameters to these APIs which previously would have generated a compiler warning. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Rename LE_SCANNING_* macrosAndre Guedes
This patch renames LE_SCANNING_ENABLED and LE_SCANNING_DISABLED macros to LE_SCAN_ENABLE and LE_SCAN_DISABLE in order to keep the same prefix others LE scan macros have. It also fixes le_scan_enable_req function so it uses the LE_SCAN_ ENABLE macro instead of a magic number. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Add macros for filter duplicates valuesAndre Guedes
This patch adds macros for filter_duplicates parameter values from HCI LE Set Scan Enable command. It also fixes le_scan_enable_req function so it uses the LE_SCAN_FILTER_DUP_ENABLE macro instead of a magic number. The LE_SCAN_FILTER_DUP_DISABLE was also defined since it will be required to properly support the GAP Observer Role. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Add LE scan type macrosAndre Guedes
This patch adds macros for active and passive LE scan type values. The LE_SCAN_PASSIVE was also defined since it will be used in future by LE connection routine and GAP Observer Role support. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Change LE scanning timeout macrosAndre Guedes
Define LE scanning timeout macros in jiffies just like we do for others timeout macros. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Add reading of all local feature pagesJohan Hedberg
With the introduction of CSA4 there is now also a features page number 2 available. This patch increments the maximum supported page number to 2 and adds code for reading all available pages (as long as we have support for them - indicated by HCI_MAX_PAGES). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Track feature pages in a single tableJohan Hedberg
The local and remote features are organized by page number. Page 0 are the LMP features, page 1 the host features, and any pages beyond 1 features that future core specification versions may define. So far we've only had the first two pages and two separate variables has been convenient enough, however with the introduction of Core Specification Addendum 4 there are features defined on page 2. Instead of requiring the addition of a new variable each time a new page number is defined, this patch refactors the code to use a single table for the features. The patch needs to update both the hci_dev and hci_conn structures since there are macros that depend on the features being represented in the same way in both of them. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Move and rename hci_conn_acceptFrédéric Dalleau
Since this function is only used by sco, move it from hci_event.c to sco.c and rename to sco_conn_defer_accept. Make it static. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-18Bluetooth: Fix incorrect SSP mode bit for non SSP devicesJaganath Kanakkassery
Some faulty non SSP devices send extended inquiry response during device discovery which is a violation of 2.1 specification. So for these devices we set SSP bit during acl connection initiation thinking that it is an SSP device. But for these devices, in remote host features event SSP supported bit will be off. But we are not clearing the SSP bit in that case and eventually SSP bit in conn flag will be incorrectly set for these devices. The software which has caused this issue is MecApp http://www.mecel.se/products/bluetooth/downloads/MecApp_download This patch does a workaround by clearing the SSP bit if it is not supported in remote host features event hcidump log ---------- < HCI Command: Inquiry (0x01|0x0001) plen 5 lap 0x9e8b33 len 4 num 0 > HCI Event: Command Status (0x0f) plen 4 Inquiry (0x01|0x0001) status 0x00 ncmd 1 > HCI Event: Extended Inquiry Result (0x2f) plen 255 bdaddr 00:1B:DC:05:B5:25 mode 1 clkoffset 0x3263 class 0x3c0000 rssi -77 Unknown type 0x42 with 8 bytes data Unknown type 0x1e with 2 bytes data > HCI Event: Inquiry Complete (0x01) plen 1 status 0x00 < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 00:1B:DC:05:B5:25 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 12 bdaddr 00:1B:DC:05:B5:25 type ACL encrypt 0x00 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 handle 12 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1 > HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 12 Features: 0xff 0xff 0x8f 0x7e 0xd8 0x1f 0x5b 0x87 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 handle 12 page 1 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7 bdaddr 00:1B:DC:05:B5:25 mode 1 > HCI Event: Max Slots Change (0x1b) plen 3 handle 12 slots 5 > HCI Event: Read Remote Extended Features (0x23) plen 13 status 0x00 handle 12 page 1 max 0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 < HCI Command: Remote Name Request (0x01|0x0019) plen 10 bdaddr 00:1B:DC:05:B5:25 mode 2 clkoffset 0x0000 > HCI Event: Command Status (0x0f) plen 4 Remote Name Request (0x01|0x0019) status 0x00 ncmd 1 > HCI Event: Remote Name Req Complete (0x07) plen 255 status 0x00 bdaddr 00:1B:DC:05:B5:25 name 'Bluetooth PTS Radio v4' < HCI Command: Authentication Requested (0x01|0x0011) plen 2 handle 12 > HCI Event: Command Status (0x0f) plen 4 Authentication Requested (0x01|0x0011) status 0x00 ncmd 1 > HCI Event: Link Key Request (0x17) plen 6 bdaddr 00:1B:DC:05:B5:25 < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6 bdaddr 00:1B:DC:05:B5:25 > HCI Event: Command Complete (0x0e) plen 10 Link Key Request Negative Reply (0x01|0x000c) ncmd 1 status 0x00 bdaddr 00:1B:DC:05:B5:25 > HCI Event: PIN Code Request (0x16) plen 6 bdaddr 00:1B:DC:05:B5:25 Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: fix sending output reports on intr channelDavid Herrmann
According to the specifications, data output reports must be sent on the interrupt channel. See also usbhid implementation. Sending these reports on the control channel breaks newer Wii Remotes. Note that this will make output reports asynchronous. However, that's how hid_output_raw_report() is supposed to work with HID_OUTPUT_REPORT as report type. There are no responses to output reports. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: don't send boot-protocol messages as HID-reportsDavid Herrmann
If a device is registered as HID device, it is always in Report-Mode. Therefore, we must not send Boot-Protocol messages on hidinput_input_event() callbacks. This confuses devices and may cause disconnects on protocol errors. We disable the hidinput_input_event() callback for now. We can implement it properly later, but lets first fix the current code by disabling it. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: merge 'send' functions into hidp_send_message()David Herrmann
We handle skb buffers all over the place, even though we have hidp_send_*_message() helpers. This creates a more generic hidp_send_message() helper and uses it instead of dealing with transmit queues directly everywhere. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: merge hidp_process_{ctrl,intr}_transmit()David Herrmann
Both hidp_process_ctrl_transmit() and hidp_process_intr_transmit() are exactly the same apart from the transmit-queue and socket pointers. Therefore, pass them as argument and merge both functions into one so we avoid 25 lines of code-duplication. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: handle kernel_sendmsg() errors correctlyDavid Herrmann
We shouldn't push back the skbs if kernel_sendmsg() fails. Instead, we terminate the connection and drop the skb. Only on EAGAIN we push it back and return. l2cap doesn't return EAGAIN, yet, but this guarantees we're safe if it will at some time in the future. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: remove old session-managementDavid Herrmann
We have the full new session-management now available so lets switch over and remove all the old code. Few semantics changed, so we need to adjust the sock.c callers a bit. But this mostly simplifies the logic. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: add new session-management helpersDavid Herrmann
This is a rewrite of the HIDP session management. It implements HIDP as an l2cap_user sub-module so we get proper notification when the underlying connection goes away. The helpers are not yet used but only added in this commit. The old session management is still used and will be removed in a following patch. The old session-management was flawed. Hotplugging is horribly broken and we have no way of getting notified when the underlying connection goes down. The whole idea of removing the HID/input sub-devices from within the session itself is broken and suffers from major dead-locks. We never can guarantee that the session can unregister itself as long as we use synchronous shutdowns. This can only work with asynchronous shutdowns. However, in this case we _must_ be able to unregister the session from the outside as otherwise the l2cap_conn object might be unlinked before we are. The new session-management is based on l2cap_user. There is only one way how to add a session and how to delete a session: "probe" and "remove" callbacks from l2cap_user. This guarantees that the session can be registered and unregistered at _any_ time without any synchronous shutdown. On the other hand, much work has been put into proper session-refcounting. We can unregister/unlink the session only if we can guarantee that it will stay alive. But for asynchronous shutdowns we never know when the last user goes away so we must use proper ref-counting. The old ->conn field has been renamed to ->hconn so we can reuse ->conn in the new session management. No other existing HIDP code is modified. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: l2cap: add l2cap_user sub-modulesDavid Herrmann
Several sub-modules like HIDP, rfcomm, ... need to track l2cap connections. The l2cap_conn->hcon->dev object is used as parent for sysfs devices so the sub-modules need to be notified when the hci_conn object is removed from sysfs. As submodules normally use the l2cap layer, the l2cap_user objects are registered there instead of on the underlying hci_conn object. This avoids any direct dependency on the HCI layer and lets the l2cap core handle any specifics. This patch introduces l2cap_user objects which contain a "probe" and "remove" callback. You can register them on any l2cap_conn object and if it is active, the "probe" callback will get called. Otherwise, an error is returned. The l2cap_conn object will call your "remove" callback directly before it is removed from user-space. This allows you to remove your submodules _before_ the parent l2cap_conn and hci_conn object is removed. At any time you can asynchronously unregister your l2cap_user object if your submodule vanishes before the l2cap_conn object does. There is no way around l2cap_user. If we want wire-protocols in the kernel, we always want the hci_conn object as parent in the sysfs tree. We cannot use a channel here since we might need multiple channels for a single protocol. But the problem is, we _must_ get notified when an l2cap_conn object is removed. We cannot use reference-counting for object-removal! This is not how it works. If a hardware is removed, we should immediately remove the object from sysfs. Any other behavior would be inconsistent with the rest of the system. Also note that device_del() might sleep, but it doesn't wait for user-space or block very long. It only _unlinks_ the object from sysfs and the whole device-tree. Everything else is handled by ref-counts! This is exactly what the other sub-modules must do: unlink their devices when the "remove" l2cap_user callback is called. They should not do any cleanup or synchronous shutdowns. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: l2cap: introduce l2cap_conn ref-countingDavid Herrmann
If we want to use l2cap_conn outside of l2cap_core.c, we need refcounting for these objects. Otherwise, we cannot synchronize l2cap locks with outside locks and end up with deadlocks. Hence, introduce ref-counting for l2cap_conn objects. This doesn't affect l2cap internals at all, as they use a direct synchronization. We also keep a reference to the parent hci_conn for locking purposes as l2cap_conn depends on this. This doesn't affect the connection itself but only the lifetime of the (dead) object. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: move hidp_schedule() to core.cDavid Herrmann
There is no reason to keep this helper in the header file. No other file depends on it so move it into hidp/core.c where it belongs. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: test "terminate" before sleepingDavid Herrmann
The "terminate" flag is guaranteed to be set before the session terminates and the handlers are woken up. Hence, we need to add it to the sleep-condition. Note that testing the flags is not enough as nothing prevents us from setting the flags again after the session-handler terminated. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: hidp: remove unused session->state fieldDavid Herrmann
This field is always BT_CONNECTED. Remove it and set it to BT_CONNECTED in hidp_copy_session() unconditionally. Also note that this field is totally bogus. Userspace can query an hidp-session for its state. However, whenever user-space queries us, this field should be BT_CONNECTED. If it wasn't BT_CONNECTED, then we would be currently cleaning up the session and the session itself would exit in the next few milliseconds. Hence, there is no reason to let user-space know that the session will exit now if they cannot make _any_ use of that. Thus, remove the field and let user-space think that a session is always BT_CONNECTED as long as they can query it. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: introduce hci_conn ref-countingDavid Herrmann
We currently do not allow using hci_conn from outside of HCI-core. However, several other users could make great use of it. This includes HIDP, rfcomm and all other sub-protocols that rely on an active connection. Hence, we now introduce hci_conn ref-counting. We currently never call get_device(). put_device() is exclusively used in hci_conn_del_sysfs(). Hence, we currently never have a greater device-refcnt than 1. Therefore, it is safe to move the put_device() call from hci_conn_del_sysfs() to hci_conn_del() (it's the only caller). In fact, this even fixes a "use-after-free" bug as we access hci_conn after calling hci_conn_del_sysfs() in hci_conn_del(). From now on we can add references to hci_conn objects in other layers (like l2cap_sock, HIDP, rfcomm, ...) and grab a reference via hci_conn_get(). This does _not_ guarantee, that the connection is still alive. But, this isn't what we want. We can simply lock the hci_conn device and use "device_is_registered(hci_conn->dev)" to test that. However, this is hardly necessary as outside users should never rely on the HCI connection to be alive, anyway. Instead, they should solely rely on the device-object to be available. But if sub-devices want the hci_conn object as sysfs parent, they need to be notified when the connection drops. This will be introduced in later patches with l2cap_users. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-17Bluetooth: remove unneeded hci_conn_hold/put_device()David Herrmann
hci_conn_hold/put_device() is used to control when hci_conn->dev is no longer needed and can be deleted from the system. Lets first look how they are currently used throughout the code (excluding HIDP!). All code that uses hci_conn_hold_device() looks like this: ... hci_conn_hold_device(); hci_conn_add_sysfs(); ... On the other side, hci_conn_put_device() is exclusively used in hci_conn_del(). So, considering that hci_conn_del() must not be called twice (which would fail horribly), we know that hci_conn_put_device() is only called _once_ (which is in hci_conn_del()). On the other hand, hci_conn_add_sysfs() must not be called twice, either (it would call device_add twice, which breaks the device, see drivers/base/core.c). So we know that hci_conn_hold_device() is also called only once (it's only called directly before hci_conn_add_sysfs()). So hold and put are known to be called only once. That means we can safely remove them and directly call hci_conn_del_sysfs() in hci_conn_del(). But there is one issue left: HIDP also uses hci_conn_hold/put_device(). However, this case can be ignored and simply removed as it is totally broken. The issue is, the only thing HIDP delays with hci_conn_hold_device() is the removal of the hci_conn->dev from sysfs. But, the hci_conn device has no mechanism to get notified when its own parent (hci_dev) gets removed from sysfs. hci_dev_hold/put() does _not_ control when it is removed but only when the device object is created and destroyed. And hci_dev calls hci_conn_flush_*() when it removes itself from sysfs, which itself causes hci_conn_del() to be called, but it does _not_ cause hci_conn_del_sysfs() to be called, which is wrong. Hence, we fix it to call hci_conn_del_sysfs() in hci_conn_del(). This guarantees that a hci_conn object is removed from sysfs _before_ its parent hci_dev is removed. The changes to HIDP look scary, wrong and broken. However, if you look at the HIDP session management, you will notice they're already broken in the exact _same_ way (ever tried "unplugging" HIDP devices? Breaks _all_ the time). So this patch only makes HIDP look _scary_ and _obviously broken_. It does not break HIDP itself, it already is! See later patches in this series which fix HIDP to use proper session-management. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-11Bluetooth: Reject SCO when hci connection timeoutsClaudio Takahasi
This patch sends Reject Synchronous Connection Request Command when hci_conn_timeout is triggered, and the SCO connection is in BT_CONNECT2 state. It prevents inconsistency if the remote host doesn't implement properly the timeout for the connection request, and it removes the connection reference left when the socket is closed for incoming SCO connections. [ 2650.129080] sco_sock_release: sock ffff8801ca417400, sk ffff88020c408800 [ 2650.129092] sco_sock_clear_timer: sock ffff88020c408800 state 6 [ 2650.129101] __sco_sock_close: sk ffff88020c408800 state 6 socket ffff8801ca417400 [ 2650.129108] sco_chan_del: sk ffff88020c408800, conn ffff8801c650ea20, err 104 [ 2650.129114] hci_conn_put: hcon ffff88020c40a800 orig refcnt 1 [ 2650.129128] sco_sock_kill: sk ffff88020c408800 state 9 [ 2650.129135] sco_sock_destruct: sk ffff88020c408800 [ 2650.138468] hci_conn_timeout: hcon ffff88020c40a800 state BT_CONNECT2 Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-11Bluetooth: Remove unneeded parameterClaudio Takahasi
This patch removes the status parameter of the l2cap_conn_add function. The parameter 'status' is always 0. Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-11Bluetooth: Minor coding style fixClaudio Takahasi
This patch removes unneeded initialization and empty line. Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-11Bluetooth: Use GFP_KERNEL in sco_conn_addClaudio Takahasi
This patch changes the memory allocation flags in the sco_conn_add function, replacing the type to GFP_KERNEL. This function is executed in process context and it is not called inside an atomic section. Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-11Bluetooth: Fix SCO connection referenceClaudio Takahasi
This patch fixes decrementing SCO connection reference right after stablishing the SCO connection with defer setup enabled. The dump below shows a disconnection command with handle 0, the connection is still in BT_CONNECT2 state and there isn't a handle associated with it. < HCI Command: Accept Synchronous Connection (0x01|0x0029) plen 21 bdaddr 78:47:1D:B3:72:6C > HCI Event: Command Status (0x0f) plen 4 Accept Synchronous Connection (0x01|0x0029) status 0x00 ncmd 1 < HCI Command: Disconnect (0x01|0x0006) plen 3 handle 0 reason 0x13 Reason: Remote User Terminated Connection > HCI Event: Command Status (0x0f) plen 4 Disconnect (0x01|0x0006) status 0x00 ncmd 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x00 handle 46 bdaddr 78:47:1D:B3:72:6C type eSCO Air mode: CVSD < SCO data: handle 46 flags 0x00 dlen 48 Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-11Bluetooth: rename hci_conn_put to hci_conn_dropDavid Herrmann
We use _get() and _put() for device ref-counting in the kernel. However, hci_conn_put() is _not_ used for ref-counting, hence, rename it to hci_conn_drop() so we can later fix ref-counting and introduce hci_conn_put(). hci_conn_hold() and hci_conn_put() are currently used to manage how long a connection should be held alive. When the last user drops the connection, we spawn a delayed work that performs the disconnect. Obviously, this has nothing to do with ref-counting for the _object_ but rather for the keep-alive of the connection. But we really _need_ proper ref-counting for the _object_ to allow connection-users like rfcomm-tty, HIDP or others. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-04-10Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem Conflicts: drivers/net/wireless/rt2x00/rt2x00pci.c net/mac80211/sta_info.c net/wireless/core.h
2013-04-09bluetooth: fix race in bt_procfs_init()Al Viro
use proc_create_data() rather than set ->data after the file has been created Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>