| Age | Commit message (Collapse) | Author |
|---|
|
hes-tracking-fix-stray-endmenu-patch-1232632040-1232632141
pending-tracking-hist top was MERGE-via-stable-tracking-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040-1232632141 / fdf777a63bcb59e0dfd78bfe2c6242e01f6d4eb9 ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-stable-tracking-hist-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040
stable-tracking-hist top was MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040 / 90463bfd2d5a3c8b52f6e6d71024a00e052b0ced ... parent commitmessage:
From: merge <null@invalid>
MERGE-via-mokopatches-tracking-hist-fix-stray-endmenu-patch
mokopatches-tracking-hist top was fix-stray-endmenu-patch / 3630e0be570de8057e7f8d2fe501ed353cdf34e6 ... parent commitmessage:
From: Andy Green <andy@openmoko.com>
fix-stray-endmenu.patch
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Many-many code in the kernel initialized the timer->function
and timer->data together with calling init_timer(timer). There
is already a helper for this. Use it for networking code.
The patch is HUGE, but makes the code 130 lines shorter
(98 insertions(+), 228 deletions(-)).
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch does the full kthread conversion for the RFCOMM protocol. It
makes the code slightly simpler and more maintainable.
Based on a patch from Christoph Hellwig <hch@lst.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Currently, the freezer treats all tasks as freezable, except for the kernel
threads that explicitly set the PF_NOFREEZE flag for themselves. This
approach is problematic, since it requires every kernel thread to either
set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
care for the freezing of tasks at all.
It seems better to only require the kernel threads that want to or need to
be frozen to use some freezer-related code and to remove any
freezer-related code from the other (nonfreezable) kernel threads, which is
done in this patch.
The patch causes all kernel threads to be nonfreezable by default (ie. to
have PF_NOFREEZE set by default) and introduces the set_freezable()
function that should be called by the freezable kernel threads in order to
unset PF_NOFREEZE. It also makes all of the currently freezable kernel
threads call set_freezable(), so it shouldn't cause any (intentional)
change of behaviour to appear. Additionally, it updates documentation to
describe the freezing of tasks more accurately.
[akpm@linux-foundation.org: build fixes]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The RFCOMM specification says that the device closing the last DLC on
a particular session is responsible for closing the multiplexer by
closing the corresponding L2CAP channel.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
The kernel provides a new convenient way to access the sockets API for
in-kernel users. It is a good idea to actually use it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Set TASK_INTERRUPTIBLE prior to testing the flag to avoid missed wakeups.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
So that it is also an offset from skb->head, reduces its size from 8 to 4 bytes
on 64bit architectures, allowing us to combine the 4 bytes hole left by the
layer headers conversion, reducing struct sk_buff size to 256 bytes, i.e. 4
64byte cachelines, and since the sk_buff slab cache is SLAB_HWCACHE_ALIGN...
:-)
Many calculations that previously required that skb->{transport,network,
mac}_header be first converted to a pointer now can be done directly, being
meaningful as offsets or pointers.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Some return values of the driver core register and create functions
are not handled and so might cause unexpected problems.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
In case of non-blocking socket calls we should return EINPROGRESS
and not EAGAIN.
Signed-off-by: Ulisses Furquim <ulissesf@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Some Bluetooth RFCOMM implementations try to negotiate a bigger channel
MTU than we can support for a particular session. The maximum MTU for
a RFCOMM session is limited through the L2CAP layer. So if the other
side proposes a channel MTU that is bigger than the underlying L2CAP
MTU, we should reduce it to the L2CAP MTU of the session minus five
bytes for the RFCOMM headers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch makes the remaining transitions to use kzalloc().
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch adds the support for RFCOMM role switching before the
connection is fully established.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch adds the module parameter disable_cfc which can be used to
disable the credit based flow control. The credit based flow control
was introduced with the Bluetooth 1.1 specification and devices can
negotiate its support, but for testing purpose it is helpful to allow
disabling of it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch converts the Bluetooth class devices into real devices. The
Bluetooth class is kept and the driver core provides the appropriate
symlinks for backward compatibility.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
|
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch reduces the default L2CAP MTU for all RFCOMM connections
from 1024 to 1013 to improve the interoperability with some broken
RFCOMM implementations. To make this more flexible the L2CAP MTU
becomes also a module parameter and so it can changed at runtime.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch removes all relics of the /proc usage from the Bluetooth
subsystem core and its upper layers. All the previous information are
now available via /sys/class/bluetooth through appropriate functions.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch moves rfcomm_crc_table[] into the RFCOMM core, because there
is no need to keep it in a separate file.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
- added typedef unsigned int __nocast gfp_t;
- replaced __nocast uses for gfp flags with gfp_t - it gives exactly
the same warnings as far as sparse is concerned, doesn't change
generated code (from gcc point of view we replaced unsigned int with
typedef) and documents what's going on far better.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
This patch fixes the sparse warnings "implicit cast to nocast type"
for the priority or gfp_mask parameters of the memory allocations.
Signed-off-by: Victor Fusco <victor@cetuc.puc-rio.br>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch implements the remote port negotiation (RPN) of the RFCOMM
protocol for Bluetooth.
Signed-off-by: J. Suter <jsuter@hardwave.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The fix for the reference counting problem of the signal DLC introduced
a race condition which leads to an oops. The reason for it is not fully
understood by now and so revert this fix, because the reference counting
problem is not crashing the RFCOMM layer and its appearance it rare.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
