aboutsummaryrefslogtreecommitdiffstats
path: root/net/bluetooth/rfcomm
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Add RFCOMM option to use L2CAP ERTM modeMarcel Holtmann2009-12-031-0/+6
| | | | | | | | By default the RFCOMM layer would still use L2CAP basic mode. For testing purposes this option enables RFCOMM to select enhanced retransmission mode. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* net: pass kern to net_proto_family create functionEric Paris2009-11-051-1/+2
| | | | | | | | | | | The generic __sock_create function has a kern argument which allows the security system to make decisions based on if a socket is being created by the kernel or by userspace. This patch passes that flag to the net_proto_family specific create function, so it can do the same thing. Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Generalize socket rx gap / receive queue overflow cmsgNeil Horman2009-10-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a new socket level option to report number of queue overflows Recently I augmented the AF_PACKET protocol to report the number of frames lost on the socket receive queue between any two enqueued frames. This value was exported via a SOL_PACKET level cmsg. AFter I completed that work it was requested that this feature be generalized so that any datagram oriented socket could make use of this option. As such I've created this patch, It creates a new SOL_SOCKET level option called SO_RXQ_OVFL, which when enabled exports a SOL_SOCKET level cmsg that reports the nubmer of times the sk_receive_queue overflowed between any two given frames. It also augments the AF_PACKET protocol to take advantage of this new feature (as it previously did not touch sk->sk_drops, which this patch uses to record the overflow count). Tested successfully by me. Notes: 1) Unlike my previous patch, this patch simply records the sk_drops value, which is not a number of drops between packets, but rather a total number of drops. Deltas must be computed in user space. 2) While this patch currently works with datagram oriented protocols, it will also be accepted by non-datagram oriented protocols. I'm not sure if thats agreeable to everyone, but my argument in favor of doing so is that, for those protocols which aren't applicable to this option, sk_drops will always be zero, and reporting no drops on a receive queue that isn't used for those non-participating protocols seems reasonable to me. This also saves us having to code in a per-protocol opt in mechanism. 3) This applies cleanly to net-next assuming that commit 977750076d98c7ff6cbda51858bb5a5894a9d9ab (my af packet cmsg patch) is reverted Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: mark net_proto_ops as constStephen Hemminger2009-10-071-1/+1
| | | | | | | All usages of structure net_proto_ops should be declared const. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Make setsockopt() optlen be unsigned.David S. Miller2009-09-301-2/+2
| | | | | | | | | | | | This provides safety against negative optlen at the type level instead of depending upon (sometimes non-trivial) checks against this sprinkled all over the the place, in each and every implementation. Based upon work done by Arjan van de Ven and feedback from Linus Torvalds. Signed-off-by: David S. Miller <davem@davemloft.net>
* Bluetooth: Fix rejected connection not disconnecting ACL linkLuiz Augusto von Dentz2009-08-221-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | When using DEFER_SETUP on a RFCOMM socket, a SABM frame triggers authorization which when rejected send a DM response. This is fine according to the RFCOMM spec: the responding implementation may replace the "proper" response on the Multiplexer Control channel with a DM frame, sent on the referenced DLCI to indicate that the DLCI is not open, and that the responder would not grant a request to open it later either. But some stacks doesn't seems to cope with this leaving DLCI 0 open after receiving DM frame. To fix it properly a timer was introduced to rfcomm_session which is used to set a timeout when the last active DLC of a session is unlinked, this will give the remote stack some time to reply with a proper DISC frame on DLCI 0 avoiding both sides sending DISC to each other on stacks that follow the specification and taking care of those who don't by taking down DLCI 0. Signed-off-by: Luiz Augusto von Dentz <luiz.dentz@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Coding style cleanup from previous rfcomm_init bug fixMarcel Holtmann2009-08-221-13/+15
| | | | | | | | The rfcomm_init bug fix went into the kernel premature before it got fully reviewed and acknowledged by the Bluetooth maintainer. So fix up the coding style now. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* bluetooth: rfcomm_init bug fixDave Young2009-08-032-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | rfcomm tty may be used before rfcomm_tty_driver initilized, The problem is that now socket layer init before tty layer, if userspace program do socket callback right here then oops will happen. reporting in: http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2 make 3 changes: 1. remove #ifdef in rfcomm/core.c, make it blank function when rfcomm tty not selected in rfcomm.h 2. tune the rfcomm_init error patch to ensure tty driver initilized before rfcomm socket usage. 3. remove __exit for rfcomm_cleanup_sockets because above change need call it in a __init function. Reported-by: Oliver Hartkopp <oliver@hartkopp.net> Tested-by: Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Bluetooth: Remove pointless endian conversion helpersMarcel Holtmann2009-06-081-6/+6
| | | | | | | | The Bluetooth source uses some endian conversion helpers, that in the end translate to kernel standard routines. So remove this obfuscation since it is fully pointless. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix removing of RFCOMM DLC timer with DEFER_SETUPJohan Hedberg2009-04-191-0/+2
| | | | | | | | | | | | | There is a missing call to rfcomm_dlc_clear_timer in the case that DEFER_SETUP is used and so the connection gets disconnected after the timeout even if it was successfully accepted previously. This patch adds a call to rfcomm_dlc_clear_timer to rfcomm_dlc_accept which will get called when the user accepts the connection by calling read() on the socket. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* proc tty: remove struct tty_operations::read_procAlexey Dobriyan2009-04-011-6/+0
| | | | | | | | | | struct tty_operations::proc_fops took it's place and there is one less create_proc_read_entry() user now! Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller2009-03-261-2/+3
|\ | | | | | | | | Conflicts: drivers/net/wimax/i2400m/usb-notif.c
| * Driver core: Fix device_move() vs. dpm list ordering, v2Cornelia Huck2009-03-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dpm_list currently relies on the fact that child devices will be registered after their parents to get a correct suspend order. Using device_move() however destroys this assumption, as an already registered device may be moved under a newly registered one. This patch adds a new argument to device_move(), allowing callers to specify how dpm_list should be adapted. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | Bluetooth: Fix RFCOMM usage of in-kernel L2CAP socketsMarcel Holtmann2009-02-271-0/+3
| | | | | | | | | | | | | | | | | | The CID value of L2CAP sockets need to be set to zero. All userspace applications do this via memset() on the sockaddr_l2 structure. The RFCOMM implementation uses in-kernel L2CAP sockets and so it has to make sure that l2_cid is set to zero. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Change RFCOMM to use BT_CONNECT2 for BT_DEFER_SETUPMarcel Holtmann2009-02-271-0/+11
| | | | | | | | | | | | | | | | | | When BT_DEFER_SETUP is enabled on a RFCOMM socket, then switch its current state from BT_OPEN to BT_CONNECT2. This gives the Bluetooth core a unified way to handle L2CAP and RFCOMM sockets. The BT_CONNECT2 state is designated for incoming connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Use general bonding whenever possibleMarcel Holtmann2009-02-271-1/+15
| | | | | | | | | | | | | | | | When receiving incoming connection to specific services, always use general bonding. This ensures that the link key gets stored and can be used for further authentications. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: When encryption is dropped, do not send RFCOMM packetsJaikumar Ganesh2009-02-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | During a role change with pre-Bluetooth 2.1 devices, the remote side drops the encryption of the RFCOMM connection. We allow a grace period for the encryption to be re-established, before dropping the connection. During this grace period, the RFCOMM_SEC_PENDING flag is set. Check this flag before sending RFCOMM packets. Signed-off-by: Jaikumar Ganesh <jaikumar@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Update version numbersMarcel Holtmann2009-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | With the support for the enhanced security model and the support for deferring connection setup, it is a good idea to increase various version numbers. This is purely cosmetic and has no effect on the behavior, but can be really helpful when debugging problems in different kernel versions. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Restrict application of socket optionsMarcel Holtmann2009-02-271-0/+16
| | | | | | | | | | | | | | | | | | | | | | The new socket options should only be evaluated for SOL_BLUETOOTH level and not for every other level. Previously this causes some minor issues when detecting if a kernel with certain features is available. Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for the RFCOMM protocol. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Pause RFCOMM TX when encryption dropsMarcel Holtmann2009-02-271-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A role switch with devices following the Bluetooth pre-2.1 standards or without Encryption Pause and Resume support is not possible if encryption is enabled. Most newer headsets require the role switch, but also require that the connection is encrypted. For connections with a high security mode setting, the link will be immediately dropped. When the connection uses medium security mode setting, then a grace period is introduced where the TX is halted and the remote device gets a change to re-enable encryption after the role switch. If not re-enabled the link will be dropped. Based on initial work by Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Replace RFCOMM link mode with security levelMarcel Holtmann2009-02-272-28/+75
| | | | | | | | | | | | | | Change the RFCOMM internals to use the new security levels and remove the link mode details. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add enhanced security model for Simple PairingMarcel Holtmann2009-02-271-57/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current security model is based around the flags AUTH, ENCRYPT and SECURE. Starting with support for the Bluetooth 2.1 specification this is no longer sufficient. The different security levels are now defined as SDP, LOW, MEDIUM and SECURE. Previously it was possible to set each security independently, but this actually doesn't make a lot of sense. For Bluetooth the encryption depends on a previous successful authentication. Also you can only update your existing link key if you successfully created at least one before. And of course the update of link keys without having proper encryption in place is a security issue. The new security levels from the Bluetooth 2.1 specification are now used internally. All old settings are mapped to the new values and this way it ensures that old applications still work. The only limitation is that it is no longer possible to set authentication without also enabling encryption. No application should have done this anyway since this is actually a security issue. Without encryption the integrity of the authentication can't be guaranteed. As default for a new L2CAP or RFCOMM connection, the LOW security level is used. The only exception here are the service discovery sessions on PSM 1 where SDP level is used. To have similar security strength as with a Bluetooth 2.0 and before combination key, the MEDIUM level should be used. This is according to the Bluetooth specification. The MEDIUM level will not require any kind of man-in-the-middle (MITM) protection. Only the HIGH security level will require this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Add support for deferring RFCOMM connection setupMarcel Holtmann2009-02-272-16/+84
| | | | | | | | | | | | | | | | | | | | | | | | In order to decide if listening RFCOMM sockets should be accept()ed the BD_ADDR of the remote device needs to be known. This patch adds a socket option which defines a timeout for deferring the actual connection setup. The connection setup is done after reading from the socket for the first time. Until then writing to the socket returns ENOTCONN. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Preparation for usage of SOL_BLUETOOTHMarcel Holtmann2009-02-271-2/+49
| | | | | | | | | | | | | | | | | | | | The socket option levels SOL_L2CAP, SOL_RFOMM and SOL_SCO are currently in use by various Bluetooth applications. Going forward the common option level SOL_BLUETOOTH should be used. This patch prepares the clean split of the old and new option levels while keeping everything backward compatibility. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Fix issue with return value of rfcomm_sock_sendmsg()Victor Shcherbatyuk2009-02-271-1/+4
|/ | | | | | | | In case of connection failures the rfcomm_sock_sendmsg() should return an error and not a 0 value. Signed-off-by: Victor Shcherbatyuk <victor.shcherbatyuk@tomtom.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Merge branch 'master' of ↵David S. Miller2008-12-231-2/+0
|\ | | | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/ppp_generic.c
| * net: Fix module refcount leak in kernel_accept()Wei Yongjun2008-12-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel_accept() does not hold the module refcount of newsock->ops->owner, so we need __module_get(newsock->ops->owner) code after call kernel_accept() by hand. In sunrpc, the module refcount is missing to hold. So this cause kernel panic. Used following script to reproduct: while [ 1 ]; do mount -t nfs4 192.168.0.19:/ /mnt touch /mnt/file umount /mnt lsmod | grep ipv6 done This patch fixed the problem by add __module_get(newsock->ops->owner) to kernel_accept(). So we do not need to used __module_get(newsock->ops->owner) in every place when used kernel_accept(). Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | bt/rfcomm/tty: join error pathsIlpo Järvinen2008-12-141-6/+7
| | | | | | | | | | Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
* | bluetooth: Fix unused var warning properly in rfcomm_sock_ioctl().David S. Miller2008-12-091-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Stephen Rothwell points out, we don't want 'sock' here but rather we really do want 'sk'. This local var is protected by all sorts of bluetooth debugging kconfig vars, but BT_DBG() is just a straight pr_debug() call which is unconditional. pr_debug() evaluates it's args only if either DEBUG or CONFIG_DYNAMIC_PRINTK_DEBUG is defined. Solving this inside of the BT_DBG() macro is non-trivial since it's varargs. And these ifdefs are ugly. So, just mark this 'sk' thing __maybe_unused and kill the ifdefs. Signed-off-by: David S. Miller <davem@davemloft.net>
* | bluetooth: Fix rfcomm_sock_ioctl() build failure with debugging enabled.David S. Miller2008-12-091-1/+1
| | | | | | | | | | | | It's 'sock' not 'sk'. Signed-off-by: David S. Miller <davem@davemloft.net>
* | Bluetooth: Fix RFCOMM release oops when device is still in useMarcel Holtmann2008-11-301-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the following sequence of actions will reproduce the oops: 1. Create a new RFCOMM device (using RFCOMMCREATEDEV ioctl) 2. (Try to) open the device 3. Release the RFCOMM device (using RFCOMMRELEASEDEV ioctl) At this point, the "/dev/rfcomm*" device is still in use, but it is gone from the internal list, so the device id can be reused. 4. Create a new RFCOMM device with the same device id as before And now kobject will complain that the TTY already exists. (See http://lkml.org/lkml/2008/7/13/89 for a reproducible test-case.) This patch attempts to correct this by only removing the device from the internal list of devices at the final unregister stage, so that the id won't get reused until the device has been completely destructed. This should be safe as the RFCOMM_TTY_RELEASED bit will be set for the device and prevent the device from being reopened after it has been released. Based on a report from Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | Bluetooth: Enable per-module dynamic debug messagesMarcel Holtmann2008-11-303-16/+1
| | | | | | | | | | | | | | | | | | | | | | With the introduction of CONFIG_DYNAMIC_PRINTK_DEBUG it is possible to allow debugging without having to recompile the kernel. This patch turns all BT_DBG() calls into pr_debug() to support dynamic debug messages. As a side effect all CONFIG_BT_*_DEBUG statements are now removed and some broken debug entries have been fixed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | bluetooth: fix warning in net/bluetooth/rfcomm/sock.cIngo Molnar2008-11-251-0/+2
|/ | | | | | | | | | | | | | fix this warning: net/bluetooth/rfcomm/sock.c: In function ‘rfcomm_sock_ioctl’: net/bluetooth/rfcomm/sock.c:795: warning: unused variable ‘sk’ perhaps BT_DEBUG() should be improved to do printf format checking instead of the #ifdef, but that looks quite intrusive: each bluetooth .c file undefines the macro. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: David S. Miller <davem@davemloft.net>
* [Bluetooth] Consolidate maintainers informationMarcel Holtmann2008-08-181-1/+1
| | | | | | | | | | | | The Bluetooth entries for the MAINTAINERS file are a little bit too much. Consolidate them into two entries. One for Bluetooth drivers and another one for the Bluetooth subsystem. Also the MODULE_AUTHOR should indicate the current maintainer of the module and actually not the original author. Fix all Bluetooth modules to provide current maintainer information. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6Linus Torvalds2008-07-203-46/+134
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (1232 commits) iucv: Fix bad merging. net_sched: Add size table for qdiscs net_sched: Add accessor function for packet length for qdiscs net_sched: Add qdisc_enqueue wrapper highmem: Export totalhigh_pages. ipv6 mcast: Omit redundant address family checks in ip6_mc_source(). net: Use standard structures for generic socket address structures. ipv6 netns: Make several "global" sysctl variables namespace aware. netns: Use net_eq() to compare net-namespaces for optimization. ipv6: remove unused macros from net/ipv6.h ipv6: remove unused parameter from ip6_ra_control tcp: fix kernel panic with listening_get_next tcp: Remove redundant checks when setting eff_sacks tcp: options clean up tcp: Fix MD5 signatures for non-linear skbs sctp: Update sctp global memory limit allocations. sctp: remove unnecessary byteshifting, calculate directly in big-endian sctp: Allow only 1 listening socket with SO_REUSEADDR sctp: Do not leak memory on multiple listen() calls sctp: Support ipv6only AF_INET6 sockets. ...
| * Merge branch 'master' of ↵David S. Miller2008-07-193-40/+134
| |\ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6
| | * [Bluetooth] Move pending packets from RFCOMM socket to TTYMarcel Holtmann2008-07-142-2/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an incoming RFCOMM socket connection gets converted into a TTY, it can happen that packets are lost. This mainly happens with the Handsfree profile where the remote side starts sending data right away. The problem is that these packets are in the socket receive queue. So when creating the TTY make sure to copy all pending packets from the socket receive queue to a private queue inside the TTY. To make this actually work, the flow control on the newly created TTY will be disabled and only enabled again when the TTY is opened by an application. And right before that, the pending packets will be put into the TTY flip buffer. Signed-off-by: Denis Kenzior <denis.kenzior@trolltech.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Store remote modem status for RFCOMM TTYMarcel Holtmann2008-07-142-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching a RFCOMM socket to a TTY, the remote modem status might be needed later. Currently it is lost since the original configuration is done via the socket interface. So store the modem status and reply it when the socket has been converted to a TTY. Signed-off-by: Denis Kenzior <denis.kenzior@trolltech.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Use non-canonical TTY by default for RFCOMMMarcel Holtmann2008-07-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | While the RFCOMM TTY emulation can act like a real serial port, in reality it is not used like this. So to not mess up stupid applications, use the non-canonical mode by default. Signed-off-by: Denis Kenzior <denis.kenzior@trolltech.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCOMarcel Holtmann2008-07-141-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Enable the common timestamp functionality that the network subsystem provides for L2CAP, RFCOMM and SCO sockets. It is possible to either use SO_TIMESTAMP or the IOCTLs to retrieve the timestamp of the current packet. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Export details about authentication requirementsMarcel Holtmann2008-07-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the Simple Pairing support, the authentication requirements are an explicit setting during the bonding process. Track and enforce the requirements and allow higher layers like L2CAP and RFCOMM to increase them if needed. This patch introduces a new IOCTL that allows to query the current authentication requirements. It is also possible to detect Simple Pairing support in the kernel this way. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Disconnect when encryption gets disabledMarcel Holtmann2008-07-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Bluetooth specification allows to enable or disable the encryption of an ACL link at any time by either the peer or the remote device. If a L2CAP or RFCOMM connection requested an encrypted link, they will now disconnect that link if the encryption gets disabled. Higher protocols that don't care about encryption (like SDP) are not affected. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| | * [Bluetooth] Enforce security for outgoing RFCOMM connectionsMarcel Holtmann2008-07-142-34/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent tests with various Bluetooth headsets have shown that some of them don't enforce authentication and encryption when connecting. All of them leave it up to the host stack to enforce it. Non of them should allow unencrypted connections, but that is how it is. So in case the link mode settings require authentication and/or encryption it will now also be enforced on outgoing RFCOMM connections. Previously this was only done for incoming connections. This support has a small drawback from a protocol level point of view since the host stack can't really tell with 100% certainty if a remote side is already authenticated or not. So if both sides are configured to enforce authentication it will be requested twice. Most Bluetooth chips are caching this information and thus no extra authentication procedure has to be triggered over-the-air, but it can happen. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * | net: remove CVS keywordsAdrian Bunk2008-06-113-6/+0
| |/ | | | | | | | | | | | | | | This patch removes CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tty: Ldisc revampAlan Cox2008-07-201-11/+2
|/ | | | | | | | | | | | Move the line disciplines towards a conventional ->ops arrangement. For the moment the actual 'tty_ldisc' struct in the tty is kept as part of the tty struct but this can then be changed if it turns out that when it all settles down we want to refcount ldiscs separately to the tty. Pull the ldisc code out of /proc and put it with our ldisc code. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* bluetooth: rfcomm_dev_state_change deadlock fixDave Young2008-06-031-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's logic in __rfcomm_dlc_close: rfcomm_dlc_lock(d); d->state = BT_CLOSED; d->state_changed(d, err); rfcomm_dlc_unlock(d); In rfcomm_dev_state_change, it's possible that rfcomm_dev_put try to take the dlc lock, then we will deadlock. Here fixed it by unlock dlc before rfcomm_dev_get in rfcomm_dev_state_change. why not unlock just before rfcomm_dev_put? it's because there's another problem. rfcomm_dev_get/rfcomm_dev_del will take rfcomm_dev_lock, but in rfcomm_dev_add the lock order is : rfcomm_dev_lock --> dlc lock so I unlock dlc before the taken of rfcomm_dev_lock. Actually it's a regression caused by commit 1905f6c736cb618e07eca0c96e60e3c024023428 ("bluetooth : __rfcomm_dlc_close lock fix"), the dlc state_change could be two callbacks : rfcomm_sk_state_change and rfcomm_dev_state_change. I missed the rfcomm_sk_state_change that time. Thanks Arjan van de Ven <arjan@linux.intel.com> for the effort in commit 4c8411f8c115def968820a4df6658ccfd55d7f1a ("bluetooth: fix locking bug in the rfcomm socket cleanup handling") but he missed the rfcomm_dev_state_change lock issue. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* bluetooth: fix locking bug in the rfcomm socket cleanup handlingArjan van de Ven2008-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in net/bluetooth/rfcomm/sock.c, rfcomm_sk_state_change() does the following operation: if (parent && sock_flag(sk, SOCK_ZAPPED)) { /* We have to drop DLC lock here, otherwise * rfcomm_sock_destruct() will dead lock. */ rfcomm_dlc_unlock(d); rfcomm_sock_kill(sk); rfcomm_dlc_lock(d); } } which is fine, since rfcomm_sock_kill() will call sk_free() which will call rfcomm_sock_destruct() which takes the rfcomm_dlc_lock()... so far so good. HOWEVER, this assumes that the rfcomm_sk_state_change() function always gets called with the rfcomm_dlc_lock() taken. This is the case for all but one case, and in that case where we don't have the lock, we do a double unlock followed by an attempt to take the lock, which due to underflow isn't going anywhere fast. This patch fixes this by moving the stragling case inside the lock, like the other usages of the same call are doing in this code. This was found with the help of the www.kerneloops.org project, where this deadlock was observed 51 times at this point in time: http://www.kerneloops.org/search.php?search=rfcomm_sock_destruct Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2008-04-023-7/+2
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/s2io.c
| * bluetooth : __rfcomm_dlc_close lock fixDave Young2008-04-012-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lockdep warning will be trigged while rfcomm connection closing. The locks taken in rfcomm_dev_add: rfcomm_dev_lock --> d->lock In __rfcomm_dlc_close: d->lock --> rfcomm_dev_lock (in rfcomm_dev_state_change) There's two way to fix it, one is in rfcomm_dev_add we first locking d->lock then the rfcomm_dev_lock The other (in this patch), remove the locking of d->lock for rfcomm_dev_state_change because just locking "d->state = BT_CLOSED;" is enough. [ 295.002046] ======================================================= [ 295.002046] [ INFO: possible circular locking dependency detected ] [ 295.002046] 2.6.25-rc7 #1 [ 295.002046] ------------------------------------------------------- [ 295.002046] krfcommd/2705 is trying to acquire lock: [ 295.002046] (rfcomm_dev_lock){-.--}, at: [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [ 295.002046] but task is already holding lock: [ 295.002046] (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] which lock already depends on the new lock. [ 295.002046] [ 295.002046] [ 295.002046] the existing dependency chain (in reverse order) is: [ 295.002046] [ 295.002046] -> #1 (&d->lock){--..}: [ 295.002046] [<c0149b23>] check_prev_add+0xd3/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<c03d6b99>] _spin_lock+0x39/0x80 [ 295.002046] [<f89a01c0>] rfcomm_dev_add+0x240/0x360 [rfcomm] [ 295.002046] [<f89a047e>] rfcomm_create_dev+0x6e/0xe0 [rfcomm] [ 295.002046] [<f89a0823>] rfcomm_dev_ioctl+0x33/0x60 [rfcomm] [ 295.002046] [<f899facc>] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm] [ 295.002046] [<c0363d38>] sock_ioctl+0x118/0x240 [ 295.002046] [<c0194196>] vfs_ioctl+0x76/0x90 [ 295.002046] [<c0194446>] do_vfs_ioctl+0x56/0x140 [ 295.002046] [<c0194569>] sys_ioctl+0x39/0x60 [ 295.002046] [<c0104faa>] syscall_call+0x7/0xb [ 295.002046] [<ffffffff>] 0xffffffff [ 295.002046] [ 295.002046] -> #0 (rfcomm_dev_lock){-.--}: [ 295.002046] [<c0149a84>] check_prev_add+0x34/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<c03d6639>] _read_lock+0x39/0x80 [ 295.002046] [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [<c013c18c>] kthread+0x5c/0xa0 [ 295.002046] [<c0105c07>] kernel_thread_helper+0x7/0x10 [ 295.002046] [<ffffffff>] 0xffffffff [ 295.002046] [ 295.002046] other info that might help us debug this: [ 295.002046] [ 295.002046] 2 locks held by krfcommd/2705: [ 295.002046] #0: (rfcomm_mutex){--..}, at: [<f899e2eb>] rfcomm_run+0x7b/0x550 [rfcomm] [ 295.002046] #1: (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] stack backtrace: [ 295.002046] Pid: 2705, comm: krfcommd Not tainted 2.6.25-rc7 #1 [ 295.002046] [<c0128a38>] ? printk+0x18/0x20 [ 295.002046] [<c014927f>] print_circular_bug_tail+0x6f/0x80 [ 295.002046] [<c0149a84>] check_prev_add+0x34/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<c03d6639>] _read_lock+0x39/0x80 [ 295.002046] [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [<c014abd9>] ? trace_hardirqs_on+0xb9/0x130 [ 295.002046] [<c03d6e89>] ? _spin_unlock_irqrestore+0x39/0x70 [ 295.002046] [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [<c03d4559>] ? __sched_text_start+0x229/0x4c0 [ 295.002046] [<c0120000>] ? cpu_avg_load_per_task+0x20/0x30 [ 295.002046] [<f899e270>] ? rfcomm_run+0x0/0x550 [rfcomm] [ 295.002046] [<c013c18c>] kthread+0x5c/0xa0 [ 295.002046] [<c013c130>] ? kthread+0x0/0xa0 [ 295.002046] [<c0105c07>] kernel_thread_helper+0x7/0x10 [ 295.002046] ======================= Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bluetooth: replace deprecated RW_LOCK_UNLOCKED macrosRobert P. J. Day2008-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | The older RW_LOCK_UNLOCKED macros defeat lockdep state tracing so replace them with the newer __RW_LOCK_UNLOCKED macros. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.1 at 2024-12-25 03:06:48 +0000