- 14 Feb, 2014 25 commits
-
-
Peter Hurley authored
The skb truesize of a 12-byte payload with a 10-byte head/tail reserve is 768 bytes. Consequently, even with 40 tx_credits, at most 6 packets could be queued at any one time: 40 tx_credits * 127-byte mtu < 768-byte truesize * 7 This error could also cause the tx queue to apparently stall if credit flow control is disabled (where tx_credits is fixed at 5), or if the receiver only granted a limited number of tx credits (eg., less than 7). Instead, track the outstanding number of queued packets not yet sent in wmem_alloc and allow for a maximum of 40 queued packets. Report the space avail for a single write() as the mtu * number of packets left before reaching the maximum. Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Tested-By:
Alexander Holler <holler@ahsoftware.de> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Peter Hurley authored
Compute the amount of space available for a single write() within rfcomm_room(); clamp to 0 for negative values. Note this patch does not change the result of the computation. Report the amount of room returned in the debug printk. Signed-off-by:
-
Peter Hurley authored
The tty driver api design prefers no-fail writes if the driver write_room() method has previously indicated space is available to accept writes. Since this is trivially possible for the RFCOMM tty driver, do so. Introduce rfcomm_dlc_send_noerror(), which queues but does not schedule the krfcomm thread if the dlc is not yet connected (and thus does not error based on the connection state). The mtu size test is also unnecessary since the caller already chunks the written data into mtu size. Signed-off-by:
-
Peter Hurley authored
If rfcomm_dlc_open() fails, set tty into error state which returns -EIO from reads and writes. Signed-off-by:
-
Peter Hurley authored
If RFCOMM tty device registration fails, cleanup by releasing the tty_port reference to trigger rfcomm_dev destruction (rather than open-coding it). The dlc reference release is moved into rfcomm_dev_add(), which ensures cleanup in both error paths -- ie., if __rfcomm_dev_add() fails or if tty_port_register_device() fails. Fixes releasing the module reference if device registration fails. Signed-off-by:
-
Peter Hurley authored
Move rfcomm_dev allocation and initialization into new function, __rfcomm_dev_add(), to simplify resource release in error handling. Signed-off-by:
-
Peter Hurley authored
At least two different race conditions exist with multiple concurrent RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctls: * Multiple concurrent RFCOMMCREATEDEVs with RFCOMM_REUSE_DLC can mistakenly share the same DLC. * RFCOMMRELEASEDEV can destruct the rfcomm_dev still being constructed by RFCOMMCREATEDEV. Introduce rfcomm_ioctl_mutex to serialize these add/remove operations. Signed-off-by:
-
Peter Hurley authored
Functions which search lists for matching id's are more commonly named *_lookup, which is the convention in the bluetooth core as well. Signed-off-by:
-
Peter Hurley authored
The RFCOMM tty device is parented to the acl link device when the dlc state_change(BT_CONNECTED) notification is received. However, if the dlc from the RFCOMM socket is being reused (RFCOMM_REUSE_DLC is set), then the dlc may already be connected, and no notification will occur. Instead, always parent the RFCOMM tty device to the acl link device at registration time. If the acl link device is not available (eg, because the dlc is not connected) then the tty will remain unparented until the BT_CONNECTED notification is received. Fixes regression with ModemManager when the rfcomm device is created with the flag RFCOMM_REUSE_DLC. Signed-off-by:
-
Peter Hurley authored
Accessing the results of hci_conn_hash_lookup_ba() is unsafe without holding the hci_dev_lock() during the lookup. For example: CPU 0 | CPU 1 hci_conn_hash_lookup_ba | hci_conn_del rcu_read_lock | hci_conn_hash_del list_for_each_entry_rcu | list_del_rcu if (.....) | synchronize_rcu rcu_read_unlock | | hci_conn_del_sysfs | hci_dev_put | hci_conn_put | put_device (last reference) | bt_link_release | kfree(conn) return p << just freed | Even if a hci_conn reference were taken (via hci_conn_get), would not guarantee the lifetime of the sysfs device, but only safe access to the in-memory structure. Ensure the hci_conn device stays valid while the rfcomm device is reparented; rename rfcomm_get_device() to rfcomm_reparent_device() and perform the reparenting within the function while holding the hci_dev_lock. Signed-off-by: -
Peter Hurley authored
If the RFCOMM session has not yet been started (ie., session is still in BT_BOUND state) when a dlc is closed, directly close and unlink the dlc rather than sending a DISC frame that is never sent. This allows the dlci to be immediately reused rather than waiting for a 20 second timeout. Signed-off-by:
-
Peter Hurley authored
Prepare for directly closing dlc if the RFCOMM session has not yet been started; refactor the dlc disconnect logic into a separate local function, __rfcomm_dlc_disconn(). Retains functional equivalence. Signed-off-by:
-
Peter Hurley authored
Prepare for directly closing dlc if the RFCOMM session has not yet been started; refactor the deferred setup test for only those dlc states to which the test applies. Retains functional equivalence. Signed-off-by:
-
Peter Hurley authored
Merge conditional test for BT_LISTEN session state into following switch statement (which is functionally equivalent). Signed-off-by:
-
Peter Hurley authored
Only one session/channel combination may be in use at any one time. However, the failure does not occur until the tty is opened (in rfcomm_dlc_open()). Because these settings are actually bound at rfcomm device creation (via RFCOMMCREATEDEV ioctl), validate and fail before creating the rfcomm tty device. Signed-off-by:
-
Peter Hurley authored
RFCOMM tty device teardown can race with new tty device registration for the same device id: CPU 0 | CPU 1 rfcomm_dev_add | rfcomm_dev_destruct | spin_lock | list_del <== dev_id no longer used | spin_unlock spin_lock | . [search rfcomm_dev_list] | . [dev_id not in use] | . [initialize new rfcomm_dev] | . spin_unlock | . | . tty_port_register_device | tty_unregister_device Don't remove rfcomm_dev from the device list until after tty device unregistration has completed. Signed-off-by: -
Peter Hurley authored
When RFCOMM_RELEASE_ONHUP is set, the rfcomm tty driver 'takes over' the initial rfcomm_dev reference created by the RFCOMMCREATEDEV ioctl. The assumption is that the rfcomm tty driver will release the rfcomm_dev reference when the tty is freed (in rfcomm_tty_cleanup()). However, if the tty is never opened, the 'take over' never occurs, so when RFCOMMRELEASEDEV ioctl is called, the reference is not released. Track the state of the reference 'take over' so that the release is guaranteed by either the RFCOMMRELEASEDEV ioctl or the rfcomm tty driver. Note that the synchronous hangup in rfcomm_release_dev() ensures that rfcomm_tty_install() cannot race with the RFCOMMRELEASEDEV ioctl. Signed-off-by:
-
Peter Hurley authored
No logic prevents an rfcomm_dev from being released multiple times. For example, if the rfcomm_dev ref count is large due to pending tx, then multiple RFCOMMRELEASEDEV ioctls may mistakenly release the rfcomm_dev too many times. Note that concurrent ioctls are not required to create this condition. Introduce RFCOMM_DEV_RELEASED status bit which guarantees the rfcomm_dev can only be released once. NB: Since the flags are exported to userspace, introduce the status field to track state for which userspace should not be aware. Signed-off-by:
-
Peter Hurley authored
When enumerating RFCOMM devices in the rfcomm_dev_list, holding the rfcomm_dev_lock only guarantees the existence of the enumerated rfcomm_dev in memory, and not safe access to its state. Testing the device state (such as RFCOMM_TTY_RELEASED) does not guarantee the device will remain in that state for the subsequent access to the rfcomm_dev's fields, nor guarantee that teardown has not commenced. Obtain an rfcomm_dev reference for the duration of rfcomm_dev access. Signed-off-by:
-
Peter Hurley authored
rfcomm_dev_get() can return a rfcomm_dev reference for a device for which destruction may be commencing. This can happen on tty destruction, which calls rfcomm_tty_cleanup(), the last port reference may have been released but RFCOMM_TTY_RELEASED was not set. The following race is also possible: CPU 0 | CPU 1 | rfcomm_release_dev rfcomm_dev_get | . spin_lock | . dev = __rfcomm_dev_get | . if dev | . if test_bit(TTY_RELEASED) | . | !test_and_set_bit(TTY_RELEASED) | tty_port_put <<<< last reference else | tty_port_get | The reference acquire is bogus because destruction will commence with the release of the last reference. Ignore the external state change of TTY_RELEASED and instead rely on the reference acquire itself to determine if the reference is valid. Cc: Jiri Slaby <jslaby@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: -
Peter Hurley authored
The tty core supports two models for handling tty_port lifetimes; the tty_port can use the kref supplied by tty_port (which will automatically destruct the tty_port when the ref count drops to zero) or it can destruct the tty_port manually. For tty drivers that choose to use the port kref to manage the tty_port lifetime, it is not possible to safely acquire a port reference conditionally. If the last reference is released after evaluating the condition but before acquiring the reference, a bogus reference will be held while the tty_port destruction commences. Rather, only acquire a port reference if the ref count is non-zero and allow the caller to distinguish if a reference has successfully been acquired. Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-By:
-
Peter Hurley authored
This reverts commit e228b633. This is the third of a 3-patch revert, together with Revert "Bluetooth: Remove rfcomm_carrier_raised()" and Revert "Bluetooth: Always wait for a connection on RFCOMM open()". Commit 4a2fb3ec, "Bluetooth: Always wait for a connection on RFCOMM open()" open-codes blocking on tty open(), rather than using the default behavior implemented by the tty port. The reasons for reverting that patch are detailed in that changelog; this patch restores required functionality for that revert. Signed-off-by:
-
Peter Hurley authored
This reverts commit 4a2fb3ec. This is the second of a 3-patch revert, together with Revert "Bluetooth: Remove rfcomm_carrier_raised()" and Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()". Before commit cad348a1, Bluetooth: Implement .activate, .shutdown and .carrier_raised methods, tty_port_block_til_ready() was open-coded in rfcomm_tty_install() as part of the RFCOMM tty open(). Unfortunately, it did not implement non-blocking open nor CLOCAL open, but rather always blocked for carrier. This is not the expected or typical behavior for ttys, and prevents several common terminal programming idioms from working (eg., opening in non-blocking mode to initialize desired termios settings then re-opening for connection). Commit cad348a1, Bluetooth: Implement .activate, .shutdown and .carrier_raised methods, added the necessary tty_port methods to use the default tty_port_open(). However, this triggered two important user-space regressions. The first regression involves the complicated mechanism for reparenting the rfcomm tty device to the ACL link device which represents an open link to a specific bluetooth host. This regression causes ModemManager to conclude the rfcomm tty device does not front a modem so it makes no attempt to initialize an attached modem. This regression is caused by the lack of a device_move() if the dlc is already open (and not specifically related to the open-coded block_til_ready()). A more appropriate solution is submitted in "Bluetooth: Fix unsafe RFCOMM device parenting" and "Bluetooth: Fix RFCOMM parent device for reused dlc" The second regression involves "rfcomm bind" and wvdial (a ppp dialer). rfcomm bind creates a device node for a /dev/rfcomm<n>. wvdial opens that device in non-blocking mode (because it expects the connection to have already been established). In addition, subsequent writes to the rfcomm tty device fail (because the link is not yet connected; rfcomm connection begins with the actual tty open()). However, restoring the original behavior (in the patch which this reverts) was undesirable. Firstly, the original reporter notes that a trivial userspace "workaround" already exists: rfcomm connect, which creates the device node and establishes the expected connection. Secondly, the failed writes occur because the rfcomm tty driver does not buffer writes to an unconnected device; this contrasts with the dozen of other tty drivers (in fact, all of them) that do just that. The submitted patch "Bluetooth: Don't fail RFCOMM tty writes" corrects this. Thirdly, it was a long-standing bug to block on non-blocking open, which is re-fixed by revert. Signed-off-by:
-
Peter Hurley authored
This reverts commit f86772af. This is the first of a 3-patch revert, together with Revert "Bluetooth: Always wait for a connection on RFCOMM open()" and Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()". Commit 4a2fb3ec, "Bluetooth: Always wait for a connection on RFCOMM open()" open-codes blocking on tty open(), rather than using the default behavior implemented by the tty port. The reasons for reverting that patch are detailed in that changelog; this patch restores required functionality for that revert. Signed-off-by:
-
Johan Hedberg authored
Now that the LE L2CAP Connection Oriented Channel support has undergone a decent amount of testing we can make it officially supported. This patch removes the enable_lecoc module parameter which was previously needed to enable support for LE L2CAP CoC. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
- 13 Feb, 2014 15 commits
-
-
Andre Guedes authored
This patch changes hci_connect_le() so it uses the connection parameters specified for the certain device. If no parameters were configured, we use the default values. Signed-off-by:
Andre Guedes <andre.guedes@openbossa.org> Signed-off-by:
-
Andre Guedes authored
This patch adds to hdev the connection parameters list (hdev->le_ conn_params). The elements from this list (struct hci_conn_params) contains the connection parameters (for now, minimum and maximum connection interval) that should be used during the connection establishment. Moreover, this patch adds helper functions to manipulate hdev->le_ conn_params list. Some of these functions are also declared in hci_core.h since they will be used outside hci_core.c in upcoming patches. Signed-off-by:
-
Marcel Holtmann authored
The LTK key types available right now are unauthenticated and authenticated ones. Provide two simple constants for it. Signed-off-by:
-
Marcel Holtmann authored
When the ACL link is using P-256 authenticated combination key, mark the link mode as HCI_LM_FIPS. Signed-off-by:
-
Marcel Holtmann authored
This check is only used for RFCOMM connections and most likely no RFCOMM based profile will require security level 4 secure connection security policy. In case it ever does make sure that seucrity level 4 is treated as sufficient security level. Signed-off-by:
-
Marcel Holtmann authored
With support for Secure Connections it is possible to switch the controller into a mode that is called Secure Connections Only. In this mode only security level 4 connections are allowed (with the exception of security level 0 approved services). This patch just introduces the management command and setting of the right internal flags to enable this mode. It does not yet enforce it. Signed-off-by:
-
Marcel Holtmann authored
The struct smp_ltk does not need to be packed and so remove __packed. Signed-off-by:
-
Marcel Holtmann authored
The field is not a boolean, it is actually a field for a key type. So name it properly. Signed-off-by:
-
Marcel Holtmann authored
The LTK authenticated parameter is the key type of the LTK and similar to link keys there is no need to check the currently supported values. For possible future improvements, the kernel will only use key types it knows about and just ignore all the other ones. Signed-off-by:
-
Marcel Holtmann authored
When encryption for LE links has been enabled, it will always be use AES-CCM encryption. In case of BR/EDR Secure Connections, the link will also use AES-CCM encryption. In both cases track the AES-CCM status in the connection flags. Signed-off-by:
-
Marcel Holtmann authored
The function already has an unlock label which means the one extra level on indentation is not useful and just makes the code more complex. So remove it. Signed-off-by:
-
Marcel Holtmann authored
Since the use of debug keys can now be identified from the current settings information, this debugfs entry is no longer necessary. Signed-off-by:
-
Marcel Holtmann authored
Originally allowing the use of debug keys was done via the Load Link Keys management command. However this is BR/EDR specific and to be flexible and allow extending this to LE as well, make this an independent command. Signed-off-by:
-
Marcel Holtmann authored
When the controller has been enabled to allow usage of debug keys, then clearly identify that in the current settings information. Signed-off-by:
-
Andre Guedes authored
This patch moves connection attempt failure code to its own function so it can be reused in the next patch. Signed-off-by:
-
