Commit graph

77 commits

Author SHA1 Message Date
Peter Hurley
e5842cdb0f Bluetooth: rfcomm: Remove unnecessary krfcommd event
Removed superfluous event handling which was used to signal
that the rfcomm kthread had been woken. This appears to have been
used to prevent lost wakeups. Correctly ordering when the task
state is set to TASK_INTERRUPTIBLE is sufficient to prevent lost wakeups.

To prevent wakeups which occurred prior to initially setting
TASK_INTERRUPTIBLE from being lost, the main work of the thread loop -
rfcomm_process_sessions() - is performed prior to sleeping.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-08-11 19:50:26 -03:00
Waldemar Rymarkiewicz
b3b1b06158 Bluetooth: Double check sec req for pre 2.1 device
In case of pre v2.1 devices authentication request will return
success immediately if the link key already exists without any
authentication process.

That means, it's not possible to re-authenticate the link if you
already have combination key and for instance want to re-authenticate
to get the high security (use 16 digit pin).

Therefore, it's necessary to check security requirements on auth
complete event to prevent not enough secure connection.

Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-05-11 14:56:28 -03:00
Gustavo F. Padovan
8c1d787be4 Bluetooth: Move conn to struct l2cap_chan
There is no need to the socket deal directly with the channel, most of the
time it cares about the channel only.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-04-28 01:10:00 -03:00
Gustavo F. Padovan
0c1bc5c626 Bluetooth: Move more channel info to struct l2cap_chan
In this commit, omtu, imtu, flush_to, mode and sport. It also remove the
pi var from l2cap_sock_sendmsg().

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-04-28 01:09:58 -03:00
Gustavo F. Padovan
47d1ec6161 Bluetooth: Move more vars to struct l2cap_chan
In this commit all ERTM and Streaming Mode specific vars.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-04-27 18:51:35 -03:00
Gustavo F. Padovan
c531a12ae6 Bluetooth: remove l2cap_load() hack
l2cap_load() was added to trigger l2cap.ko module loading from the RFCOMM
and BNEP modules. Now that L2CAP module is gone, we don't need it anymore.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-02-15 09:45:52 -03:00
Lukáš Turek
683d949a7f Bluetooth: Never deallocate a session when some DLC points to it
Fix a bug introduced in commit 9cf5b0ea3a:
function rfcomm_recv_ua calls rfcomm_session_put without checking that
the session is not referenced by some DLC. If the session is freed, that
DLC would refer to deallocated memory, causing an oops later, as shown
in this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=15994

Signed-off-by: Lukas Turek <8an@praha12.net>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2011-01-19 14:40:42 -02:00
David S. Miller
b4aa9e05a6 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
	drivers/net/bnx2x/bnx2x.h
	drivers/net/wireless/iwlwifi/iwl-1000.c
	drivers/net/wireless/iwlwifi/iwl-6000.c
	drivers/net/wireless/iwlwifi/iwl-core.h
	drivers/vhost/vhost.c
2010-12-17 12:27:22 -08:00
Johan Hedberg
183f732c3f Bluetooth: Fix initial RFCOMM DLC security level
Due to commit 63ce0900 connections initiated through TTYs created with
"rfcomm bind ..." would have security level BT_SECURITY_SDP instead of
BT_SECURITY_LOW. This would cause instant connection failure between any
two SSP capable devices due to the L2CAP connect request to RFCOMM being
sent before authentication has been performed. This patch fixes the
regression by always initializing the DLC security level to
BT_SECURITY_LOW.

Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Acked-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2010-12-06 15:47:44 -02:00
Andrei Emeltchenko
285b4e9031 Bluetooth: clean up rfcomm code
Remove extra spaces, assignments in if statement, zeroing static
variables, extra braces. Fix includes.

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2010-12-01 21:04:43 -02:00
Luiz Augusto von Dentz
63ce0900d7 Bluetooth: fix not setting security level when creating a rfcomm session
This cause 'No Bonding' to be used if userspace has not yet been paired
with remote device since the l2cap socket used to create the rfcomm
session does not have any security level set.

Signed-off-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2010-11-09 00:56:10 -02:00
Andrei Emeltchenko
534c92fde7 Bluetooth: clean up rfcomm code
Remove dead code and unused rfcomm thread events

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2010-10-12 12:44:53 -03:00
Andrei Emeltchenko
5017d8dde1 Bluetooth: remove extra newline from debug output
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2010-10-12 12:44:51 -03:00
Yuri Kululin
08601469a5 Bluetooth: Fix RFCOMM RPN negotiation
According to the ETSI 3GPP TS 07.10 the default bit rate value for RFCOMM
is 9600 bit/s. Return this bit rate in case of RPN request and accept other
sane bit rates proposed by the sender in RPM command.

Signed-off-by: Yuri Kululin <ext-yuri.kululin@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2010-10-12 12:44:51 -03:00
Eric Dumazet
a02cec2155 net: return operator cleanup
Change "return (EXPR);" to "return EXPR;"

return is not a function, parentheses are not required.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-09-23 14:33:39 -07:00
Tejun Heo
5a0e3ad6af include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-30 22:02:32 +09:00
Marcel Holtmann
aef7d97cc6 Bluetooth: Convert debug files to actually use debugfs instead of sysfs
Some of the debug files ended up wrongly in sysfs, because at that point
of time, debugfs didn't exist. Convert these files to use debugfs and
also seq_file. This patch converts all of these files at once and then
removes the exported symbol for the Bluetooth sysfs class.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-03-21 05:49:35 +01:00
Marcel Holtmann
101545f6fe Bluetooth: Fix potential bad memory access with sysfs files
When creating a high number of Bluetooth sockets (L2CAP, SCO
and RFCOMM) it is possible to scribble repeatedly on arbitrary
pages of memory. Ensure that the content of these sysfs files is
always less than one page. Even if this means truncating. The
files in question are scheduled to be moved over to debugfs in
the future anyway.

Based on initial patches from Neil Brown and Linus Torvalds

Reported-by: Neil Brown <neilb@suse.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-03-21 05:49:32 +01:00
Andi Kleen
28812fe11a driver-core: Add attribute argument to class_attribute show/store
Passing the attribute to the low level IO functions allows all kinds
of cleanups, by sharing low level IO code without requiring
an own function for every piece of data.

Also drivers can extend the attributes with own data fields
and use that in the low level function.

This makes the class attributes the same as sysdev_class attributes
and plain attributes.

This will allow further cleanups in drivers.

Full tree sweep converting all users.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-03-07 17:04:48 -08:00
Nick Pelly
6c2718da59 Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
When processing a RFCOMM UA frame when the socket is closed and we were
not the RFCOMM initiator would cause rfcomm_session_put() to be called
twice during rfcomm_process_rx(). This would cause a kernel panic in
rfcomm_session_close() then.

This could be easily reproduced during disconnect with devices such as
Motorola H270 that send RFCOMM UA followed quickly by L2CAP disconnect
request. This trace for this looks like:

2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d
2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57
2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12
   L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041

Avoid calling rfcomm_session_put() twice by skipping this call
in rfcomm_recv_ua() if the socket is closed.

Signed-off-by: Nick Pelly <npelly@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2010-02-03 16:28:44 -08:00
Marcel Holtmann
485f1eff73 Bluetooth: Fix sleeping function in RFCOMM within invalid context
With the commit 9e726b1742 the
rfcomm_session_put() gets accidentially called from a timeout
callback and results in this:

BUG: sleeping function called from invalid context at net/core/sock.c:1897
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Pid: 0, comm: swapper Tainted: P           2.6.32 #31
Call Trace:
 <IRQ>  [<ffffffff81036455>] __might_sleep+0xf8/0xfa
 [<ffffffff8138ef1d>] lock_sock_nested+0x29/0xc4
 [<ffffffffa03921b3>] lock_sock+0xb/0xd [l2cap]
 [<ffffffffa03948e6>] l2cap_sock_shutdown+0x1c/0x76 [l2cap]
 [<ffffffff8106adea>] ? clockevents_program_event+0x75/0x7e
 [<ffffffff8106bea2>] ? tick_dev_program_event+0x37/0xa5
 [<ffffffffa0394967>] l2cap_sock_release+0x27/0x67 [l2cap]
 [<ffffffff8138c971>] sock_release+0x1a/0x67
 [<ffffffffa03d2492>] rfcomm_session_del+0x34/0x53 [rfcomm]
 [<ffffffffa03d24c5>] rfcomm_session_put+0x14/0x16 [rfcomm]
 [<ffffffffa03d28b4>] rfcomm_session_timeout+0xe/0x1a [rfcomm]
 [<ffffffff810554a8>] run_timer_softirq+0x1e2/0x29a
 [<ffffffffa03d28a6>] ? rfcomm_session_timeout+0x0/0x1a [rfcomm]
 [<ffffffff8104e0f6>] __do_softirq+0xfe/0x1c5
 [<ffffffff8100e8ce>] ? timer_interrupt+0x1a/0x21
 [<ffffffff8100cc4c>] call_softirq+0x1c/0x28
 [<ffffffff8100e05b>] do_softirq+0x33/0x6b
 [<ffffffff8104daf6>] irq_exit+0x36/0x85
 [<ffffffff8100d7a9>] do_IRQ+0xa6/0xbd
 [<ffffffff8100c493>] ret_from_intr+0x0/0xa
 <EOI>  [<ffffffff812585b3>] ? acpi_idle_enter_bm+0x269/0x294
 [<ffffffff812585a9>] ? acpi_idle_enter_bm+0x25f/0x294
 [<ffffffff81373ddc>] ? cpuidle_idle_call+0x97/0x107
 [<ffffffff8100aca0>] ? cpu_idle+0x53/0xaa
 [<ffffffff81429006>] ? rest_init+0x7a/0x7c
 [<ffffffff8177bc8c>] ? start_kernel+0x389/0x394
 [<ffffffff8177b29c>] ? x86_64_start_reservations+0xac/0xb0
 [<ffffffff8177b384>] ? x86_64_start_kernel+0xe4/0xeb

To fix this, the rfcomm_session_put() needs to be moved out of
rfcomm_session_timeout() into rfcomm_process_sessions(). In that
context it is perfectly fine to sleep and disconnect the socket.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: David John <davidjon@xenontk.org>
2010-02-03 15:52:18 -08:00
Marcel Holtmann
eae38eede2 Bluetooth: Add RFCOMM option to use L2CAP ERTM mode
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>
2009-12-03 19:34:26 +01:00
Luiz Augusto von Dentz
9e726b1742 Bluetooth: Fix rejected connection not disconnecting ACL link
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>
2009-08-22 15:05:58 -07:00
Marcel Holtmann
52d18347df Bluetooth: Coding style cleanup from previous rfcomm_init bug fix
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>
2009-08-22 14:49:36 -07:00
Dave Young
af0d3b103b bluetooth: rfcomm_init bug fix
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>
2009-08-03 13:24:39 -07:00
Marcel Holtmann
b4324b5dc5 Bluetooth: Remove pointless endian conversion helpers
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>
2009-06-08 14:50:01 +02:00
Johan Hedberg
e2139b3272 Bluetooth: Fix removing of RFCOMM DLC timer with DEFER_SETUP
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>
2009-04-19 18:56:45 +02:00
Marcel Holtmann
37e62f5516 Bluetooth: Fix RFCOMM usage of in-kernel L2CAP sockets
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>
2009-02-27 06:14:48 +01:00
Marcel Holtmann
8bf4794174 Bluetooth: Change RFCOMM to use BT_CONNECT2 for BT_DEFER_SETUP
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>
2009-02-27 06:14:47 +01:00
Marcel Holtmann
0684e5f9fb Bluetooth: Use general bonding whenever possible
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>
2009-02-27 06:14:40 +01:00
Jaikumar Ganesh
6e1031a400 Bluetooth: When encryption is dropped, do not send RFCOMM packets
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>
2009-02-27 06:14:35 +01:00
Marcel Holtmann
5f9018af00 Bluetooth: Update version numbers
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>
2009-02-27 06:14:34 +01:00
Marcel Holtmann
8c84b83076 Bluetooth: Pause RFCOMM TX when encryption drops
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>
2009-02-27 06:14:33 +01:00
Marcel Holtmann
9f2c8a03fb Bluetooth: Replace RFCOMM link mode with security level
Change the RFCOMM internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2009-02-27 06:14:26 +01:00
Marcel Holtmann
8c1b235594 Bluetooth: Add enhanced security model for Simple Pairing
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>
2009-02-27 06:14:25 +01:00
Marcel Holtmann
bb23c0ab82 Bluetooth: Add support for deferring RFCOMM connection setup
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>
2009-02-27 06:14:23 +01:00
David S. Miller
6332178d91 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:

	drivers/net/ppp_generic.c
2008-12-23 17:56:23 -08:00
Wei Yongjun
1b08534e56 net: Fix module refcount leak in kernel_accept()
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>
2008-12-18 19:35:10 -08:00
Marcel Holtmann
a418b893a6 Bluetooth: Enable per-module dynamic debug messages
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>
2008-11-30 12:17:28 +01:00
Marcel Holtmann
63fbd24e51 [Bluetooth] Consolidate maintainers information
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>
2008-08-18 13:23:53 +02:00
David S. Miller
407d819cf0 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6 2008-07-19 00:30:39 -07:00
Marcel Holtmann
a0c22f2265 [Bluetooth] Move pending packets from RFCOMM socket to TTY
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>
2008-07-14 20:13:52 +02:00
Marcel Holtmann
8b6b3da765 [Bluetooth] Store remote modem status for RFCOMM TTY
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>
2008-07-14 20:13:52 +02:00
Marcel Holtmann
40be492fe4 [Bluetooth] Export details about authentication requirements
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>
2008-07-14 20:13:50 +02:00
Marcel Holtmann
9719f8afce [Bluetooth] Disconnect when encryption gets disabled
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>
2008-07-14 20:13:45 +02:00
Marcel Holtmann
77db198056 [Bluetooth] Enforce security for outgoing RFCOMM connections
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>
2008-07-14 20:13:45 +02:00
Adrian Bunk
0b04082995 net: remove CVS keywords
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>
2008-06-11 21:00:38 -07:00
Arjan van de Ven
4c8411f8c1 bluetooth: fix locking bug in the rfcomm socket cleanup handling
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>
2008-05-29 01:32:47 -07:00
Dave Young
1905f6c736 bluetooth : __rfcomm_dlc_close lock fix
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>
2008-04-01 23:59:06 -07:00
Harvey Harrison
b5606c2d44 remove final fastcall users
fastcall always expands to empty, remove it.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-13 16:21:18 -08:00