aboutsummaryrefslogtreecommitdiffstats
path: root/net/bluetooth/rfcomm (follow)
AgeCommit message (Collapse)AuthorFilesLines
2015-12-20Bluetooth: use list_for_each_entry*Geliang Tang1-32/+14
Use list_for_each_entry*() instead of list_for_each*() to simplify the code. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-06Bluetooth: Fix potential NULL dereference in RFCOMM bind callbackJaganath Kanakkassery1-8/+12
addr can be NULL and it should not be dereferenced before NULL checking. Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-05-11net: Pass kern from net_proto_family.create to sk_allocEric W. Biederman1-4/+4
In preparation for changing how struct net is refcounted on kernel sockets pass the knowledge that we are creating a kernel socket from sock_create_kern through to sk_alloc. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-11net: Add a struct net parameter to sock_create_kernEric W. Biederman1-1/+1
This is long overdue, and is part of cleaning up how we allocate kernel sockets that don't reference count struct net. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-03-02net: Remove iocb argument from sendmsg and recvmsgYing Xue1-5/+5
After TIPC doesn't depend on iocb argument in its internal implementations of sendmsg() and recvmsg() hooks defined in proto structure, no any user is using iocb argument in them at all now. Then we can drop the redundant iocb argument completely from kinds of implementations of both sendmsg() and recvmsg() in the entire networking stack. Cc: Christoph Hellwig <hch@lst.de> Suggested-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-23Bluetooth: Fix nested sleepsPeter Hurley1-5/+4
l2cap/rfcomm/sco_sock_accept() are wait loops which may acquire sleeping locks. Since both wait loops and sleeping locks use task_struct.state to sleep and wake, the nested sleeping locks destroy the wait loop state. Use the newly-minted wait_woken() and DEFINE_WAIT_FUNC() for the wait loop. DEFINE_WAIT_FUNC() allows an alternate wake function to be specified; in this case, the predefined scheduler function, woken_wake_function(). This wait construct ensures wakeups will not be missed without requiring the wait loop to set the task state before condition evaluation. How this works: CPU 0 | CPU 1 | | is <condition> set? | no set <condition> | | wake_up_interruptible | woken_wake_function | set WQ_FLAG_WOKEN | try_to_wake_up | | wait_woken | set TASK_INTERRUPTIBLE | WQ_FLAG_WOKEN? yes | set TASK_RUNNING | | - loop - | | is <condition> set? | yes - exit wait loop Fixes "do not call blocking ops when !TASK_RUNNING" warnings in l2cap_sock_accept(), rfcomm_sock_accept() and sco_sock_accept(). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-01-12Bluetooth: Add BUILD_BUG_ON for size of struct sockaddr_rcMarcel Holtmann1-0/+2
This adds an extra check for ensuring that the size of sockaddr_rc does not grow larger than sockaddr. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-12-20Bluetooth: Remove duplicate constant for RFCOMM PSMMarcel Holtmann1-2/+2
The RFCOMM_PSM constant is actually a duplicate. So remove it and use the L2CAP_PSM_RFCOMM constant instead. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-12-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds3-7/+9
Pull networking updates from David Miller: 1) New offloading infrastructure and example 'rocker' driver for offloading of switching and routing to hardware. This work was done by a large group of dedicated individuals, not limited to: Scott Feldman, Jiri Pirko, Thomas Graf, John Fastabend, Jamal Hadi Salim, Andy Gospodarek, Florian Fainelli, Roopa Prabhu 2) Start making the networking operate on IOV iterators instead of modifying iov objects in-situ during transfers. Thanks to Al Viro and Herbert Xu. 3) A set of new netlink interfaces for the TIPC stack, from Richard Alpe. 4) Remove unnecessary looping during ipv6 routing lookups, from Martin KaFai Lau. 5) Add PAUSE frame generation support to gianfar driver, from Matei Pavaluca. 6) Allow for larger reordering levels in TCP, which are easily achievable in the real world right now, from Eric Dumazet. 7) Add a variable of napi_schedule that doesn't need to disable cpu interrupts, from Eric Dumazet. 8) Use a doubly linked list to optimize neigh_parms_release(), from Nicolas Dichtel. 9) Various enhancements to the kernel BPF verifier, and allow eBPF programs to actually be attached to sockets. From Alexei Starovoitov. 10) Support TSO/LSO in sunvnet driver, from David L Stevens. 11) Allow controlling ECN usage via routing metrics, from Florian Westphal. 12) Remote checksum offload, from Tom Herbert. 13) Add split-header receive, BQL, and xmit_more support to amd-xgbe driver, from Thomas Lendacky. 14) Add MPLS support to openvswitch, from Simon Horman. 15) Support wildcard tunnel endpoints in ipv6 tunnels, from Steffen Klassert. 16) Do gro flushes on a per-device basis using a timer, from Eric Dumazet. This tries to resolve the conflicting goals between the desired handling of bulk vs. RPC-like traffic. 17) Allow userspace to ask for the CPU upon what a packet was received/steered, via SO_INCOMING_CPU. From Eric Dumazet. 18) Limit GSO packets to half the current congestion window, from Eric Dumazet. 19) Add a generic helper so that all drivers set their RSS keys in a consistent way, from Eric Dumazet. 20) Add xmit_more support to enic driver, from Govindarajulu Varadarajan. 21) Add VLAN packet scheduler action, from Jiri Pirko. 22) Support configurable RSS hash functions via ethtool, from Eyal Perry. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1820 commits) Fix race condition between vxlan_sock_add and vxlan_sock_release net/macb: fix compilation warning for print_hex_dump() called with skb->mac_header net/mlx4: Add support for A0 steering net/mlx4: Refactor QUERY_PORT net/mlx4_core: Add explicit error message when rule doesn't meet configuration net/mlx4: Add A0 hybrid steering net/mlx4: Add mlx4_bitmap zone allocator net/mlx4: Add a check if there are too many reserved QPs net/mlx4: Change QP allocation scheme net/mlx4_core: Use tasklet for user-space CQ completion events net/mlx4_core: Mask out host side virtualization features for guests net/mlx4_en: Set csum level for encapsulated packets be2net: Export tunnel offloads only when a VxLAN tunnel is created gianfar: Fix dma check map error when DMA_API_DEBUG is enabled cxgb4/csiostor: Don't use MASTER_MUST for fw_hello call net: fec: only enable mdio interrupt before phy device link up net: fec: clear all interrupt events to support i.MX6SX net: fec: reset fep link status in suspend function net: sock: fix access via invalid file descriptor net: introduce helper macro for_each_cmsghdr ...
2014-11-24new helper: memcpy_from_msg()Al Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-11-04Bluetooth: Fix sparse warnings in RFCOMMJohan Hedberg1-2/+4
This patch fixes the following sparse warnings in rfcomm/core.c: net/bluetooth/rfcomm/core.c:391:16: warning: dubious: x | !y net/bluetooth/rfcomm/core.c:546:24: warning: dubious: x | !y Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-11-04rfcomm, sched/wait: Fix broken wait constructPeter Zijlstra1-10/+8
rfcomm_run() is a tad broken in that is has a nested wait loop. One cannot rely on p->state for the outer wait because the inner wait will overwrite it. Fix this using the new wait_woken() facility. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Peter Hurley <peter@hurleysoftware.com> Cc: Alexander Holler <holler@ahsoftware.de> Cc: David S. Miller <davem@davemloft.net> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Joe Perches <joe@perches.com> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Libor Pechacek <lpechacek@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Vignesh Raman <Vignesh_Raman@mentor.com> Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-11-02Bluetooth: Introduce BT_BREDR and BT_LE config optionsMarcel Holtmann1-1/+1
The current kernel options do not make it clear which modules are for Bluetooth Classic (BR/EDR) and which are for Bluetooth Low Energy (LE). To make it really clear, introduce BT_BREDR and BT_LE options with proper dependencies into the different modules. Both new options default to y to not create a regression with previous kernel config files. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-10-25Bluetooth: Improve RFCOMM __test_pf macro robustnessSzymon Janc1-1/+1
Value returned by this macro might be used as bit value so it should return either 0 or 1 to avoid possible bugs (similar to NSC bug) when shifting it. Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-10-25Bluetooth: Fix RFCOMM NSC responseSzymon Janc1-2/+2
rfcomm_send_nsc expects CR to be either 0 or 1 since it is later passed to __mcc_type macro and shitfed. Unfortunatelly CR extracted from received frame type was not sanitized and shifted value was passed resulting in bogus response. Note: shifted value was also passed to other functions but was used only in if satements so this bug appears only for NSC case. The CR bit in the value octet shall be set to the same value as the CR bit in the type field octet of the not supported command frame but the CR bit for NCS response should be set to 0 since it is always a response. This was affecting TC_RFC_BV_25_C PTS qualification test. Signed-off-by: Szymon Janc <szymon.janc@tieto.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-07-22Bluetooth: Avoid use of session socket after the session gets freedVignesh Raman1-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
2014-07-17Bluetooth: Pass initiator/acceptor information to hci_conn_security()Johan Hedberg1-1/+2
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>
2014-07-17Bluetooth: never linger on process exitVladimir Davydov1-1/+2
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
2014-05-29Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-nextJohn W. Linville2-11/+11
Conflicts: drivers/bluetooth/btusb.c
2014-05-05Bluetooth: Convert RFCOMM spinlocks into mutexesLibor Pechacek2-11/+11
Enabling CONFIG_DEBUG_ATOMIC_SLEEP has shown that some rfcomm functions acquiring spinlocks call sleeping locks further in the chain. Converting the offending spinlocks into mutexes makes sleeping safe. Signed-off-by: Libor Pechacek <lpechacek@suse.cz> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-04-11net: Fix use after free by removing length arg from sk_data_ready callbacks.David S. Miller2-4/+4
Several spots in the kernel perform a sequence like: skb_queue_tail(&sk->s_receive_queue, skb); sk->sk_data_ready(sk, skb->len); But at the moment we place the SKB onto the socket receive queue it can be consumed and freed up. So this skb->len access is potentially to freed up memory. Furthermore, the skb->len can be modified by the consumer so it is possible that the value isn't accurate. And finally, no actual implementation of this callback actually uses the length argument. And since nobody actually cared about it's value, lots of call sites pass arbitrary values in such as '0' and even '1'. So just remove the length argument from the callback, that way there is no confusion whatsoever and all of these use-after-free cases get fixed as a side effect. Based upon a patch by Eric Dumazet and his suggestion to audit this issue tree-wide. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-26Bluetooth: Fix returning peer address in pending connect stateJohan Hedberg1-1/+2
We should let user space request the peer address also in the pending connect states, i.e. BT_CONNECT and BT_CONNECT2. There is existing user space code that tries to do this and will fail without extending the set of allowed states for the peer address information. This patch adds the two states to the allowed ones in the L2CAP and RFCOMM sock_getname functions, thereby preventing ENOTCONN from being returned. Reported-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Tested-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-12Bluetooth: Convert uses of __constant_<foo> to <foo>Joe Perches1-2/+2
The use of __constant_<foo> has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-20Bluetooth: Fix channel check when binding RFCOMM sockAndrzej Kaczmarek1-6/+12
When binding RFCOMM socket with non-zero channel we're checking if there is already any other socket which has the same channel number assigned and then fail. This check does not consider situation where we have another socket connected to remote device on given channel number in which case we still should be able to bind local socket. This patch changes __rfcomm_get_sock_by_addr() to return only sockets in either BT_BOUND or BT_LISTEN states, also name is updated to better describe what this function does now. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix write_room() calculationPeter Hurley1-9/+5
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>
2014-02-14Bluetooth: Refactor write_room() calculationPeter Hurley1-12/+15
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Don't fail RFCOMM tty writesPeter Hurley2-16/+21
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Force -EIO from tty read/write if .activate() failsPeter Hurley1-1/+5
If rfcomm_dlc_open() fails, set tty into error state which returns -EIO from reads and writes. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Cleanup RFCOMM device registration error handlingPeter Hurley1-9/+7
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Refactor rfcomm_dev_add()Peter Hurley1-14/+24
Move rfcomm_dev allocation and initialization into new function, __rfcomm_dev_add(), to simplify resource release in error handling. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Serialize RFCOMMCREATEDEV and RFCOMMRELEASEDEV ioctlsPeter Hurley1-2/+25
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Rename __rfcomm_dev_get() to __rfcomm_dev_lookup()Peter Hurley1-2/+2
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix RFCOMM parent device for reused dlcPeter Hurley1-0/+1
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix unsafe RFCOMM device parentingPeter Hurley1-6/+14
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Directly close dlc for not yet started RFCOMM sessionPeter Hurley1-3/+9
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Refactor dlc disconnect logic in rfcomm_dlc_close()Peter Hurley1-8/+15
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Refactor deferred setup test in rfcomm_dlc_close()Peter Hurley1-10/+8
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Simplify RFCOMM session state evalPeter Hurley1-3/+2
Merge conditional test for BT_LISTEN session state into following switch statement (which is functionally equivalent). Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Verify dlci not in use before rfcomm_dev createPeter Hurley2-1/+33
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix RFCOMM tty teardown racePeter Hurley1-4/+4
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix unreleased rfcomm_dev referencePeter Hurley1-2/+4
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Release rfcomm_dev only oncePeter Hurley1-2/+9
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Exclude released devices from RFCOMMGETDEVLIST ioctlPeter Hurley1-1/+2
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Bluetooth: Fix racy acquire of rfcomm_dev referencePeter Hurley1-6/+2
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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Revert "Bluetooth: Move rfcomm_get_device() before rfcomm_dev_activate()"Peter Hurley1-16/+16
This reverts commit e228b63390536f5b737056059a9a04ea016b1abf. 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 4a2fb3ecc7467c775b154813861f25a0ddc11aa0, "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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Revert "Bluetooth: Always wait for a connection on RFCOMM open()"Peter Hurley1-38/+8
This reverts commit 4a2fb3ecc7467c775b154813861f25a0ddc11aa0. 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 cad348a17e170451ea8688b532a6ca3e98c63b60, 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 cad348a17e170451ea8688b532a6ca3e98c63b60, 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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-14Revert "Bluetooth: Remove rfcomm_carrier_raised()"Peter Hurley1-0/+8
This reverts commit f86772af6a0f643d3e13eb3f4f9213ae0c333ee4. 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 4a2fb3ecc7467c775b154813861f25a0ddc11aa0, "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 <peter@hurleysoftware.com> Tested-By: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-13Bluetooth: Refuse peer RFCOMM address reading when not connectedJohan Hedberg1-0/+3
When we're not connected the peer address information is undefined. This patch fixes the remote address getting to return a proper error in case the sate is anything else than BT_CONNECTED. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-13Bluetooth: Handle security level 4 for RFCOMM connectionsMarcel Holtmann2-2/+14
With the introduction of security level 4, the RFCOMM sockets need to be made aware of this new level. This change ensures that the pairing requirements are set correctly for these connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-01-06Bluetooth: Remove rfcomm_carrier_raised()Gianluca Anzolin1-8/+0
Remove the rfcomm_carrier_raised() definition as that function isn't used anymore. Signed-off-by: Gianluca Anzolin <gianluca@sottospazio.it> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>