linux.git/net/bluetooth/af_bluetooth.c, branch v3.5

Bluetooth: Fix checking the wrong flag when accepting a socket

2012-06-05T03:26:26+00:00

Most probably a typo, the check should have been for BT_SK_DEFER_SETUP
instead of BT_DEFER_SETUP (which right now only represents a socket
option).

Signed-off-by: Vinicius Costa Gomes 
Acked-by: Andrei Emeltchenko 
Signed-off-by: Gustavo Padovan

Bluetooth: Create flags for bt_sk()

2012-05-16T19:14:17+00:00

defer_setup and suspended are now flags into bt_sk().

Signed-off-by: Gustavo Padovan 
Signed-off-by: Johan Hedberg

Bluetooth: notify userspace of security level change

2012-05-14T17:51:25+00:00

It fixes L2CAP socket based security level elevation during a
connection. The HID profile needs this (for keyboards) and it is the only
way to achieve the security level elevation when using the management
interface to talk to the kernel (hence the management enabling patch
being the one that exposes this issue).

It enables the userspace a security level change when the socket is
already connected and create a way to notify the socket the result of the
request. At the moment of the request the socket is made non writable, if
the request fails the connections closes, otherwise the socket is made
writable again, POLL_OUT is emmited.

Signed-off-by: Gustavo Padovan 
Acked-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg 
Signed-off-by: John W. Linville

Bluetooth: silence lockdep warning

2012-02-15T11:09:26+00:00

Since bluetooth uses multiple protocols types, to avoid lockdep
warnings, we need to use different lockdep classes (one for each
protocol type).

This is already done in bt_sock_create but it misses a couple of cases
when new connections are created. This patch corrects that to fix the
following warning:

<4>[ 1864.732366] =======================================================
<4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
<4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
<4>[ 1864.733883] -------------------------------------------------------
<4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
<4>[ 1864.734869]  (rfcomm_mutex){+.+.+.}, at: [] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.735541]
<4>[ 1864.735549] but task is already holding lock:
<4>[ 1864.736045]  (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [] lock_sock+0xa/0xc
<4>[ 1864.736732]
<4>[ 1864.736740] which lock already depends on the new lock.
<4>[ 1864.736750]
<4>[ 1864.737428]
<4>[ 1864.737437] the existing dependency chain (in reverse order) is:
<4>[ 1864.738016]
<4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
<4>[ 1864.738549]        [] lock_acquire+0x104/0x140
<4>[ 1864.738977]        [] lock_sock_nested+0x58/0x68
<4>[ 1864.739411]        [] l2cap_sock_sendmsg+0x3e/0x76
<4>[ 1864.739858]        [] __sock_sendmsg+0x50/0x59
<4>[ 1864.740279]        [] sock_sendmsg+0x94/0xa8
<4>[ 1864.740687]        [] kernel_sendmsg+0x28/0x37
<4>[ 1864.741106]        [] rfcomm_send_frame+0x30/0x38
<4>[ 1864.741542]        [] rfcomm_send_ua+0x58/0x5a
<4>[ 1864.741959]        [] rfcomm_run+0x441/0xb52
<4>[ 1864.742365]        [] kthread+0x63/0x68
<4>[ 1864.742742]        [] kernel_thread_helper+0x6/0xd
<4>[ 1864.743187]
<4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
<4>[ 1864.743667]        [] __lock_acquire+0x988/0xc00
<4>[ 1864.744100]        [] lock_acquire+0x104/0x140
<4>[ 1864.744519]        [] __mutex_lock_common+0x3b/0x33f
<4>[ 1864.744975]        [] mutex_lock_nested+0x2d/0x36
<4>[ 1864.745412]        [] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.745842]        [] __rfcomm_sock_close+0x5f/0x6b
<4>[ 1864.746288]        [] rfcomm_sock_shutdown+0x2f/0x62
<4>[ 1864.746737]        [] sys_socketcall+0x1db/0x422
<4>[ 1864.747165]        [] syscall_call+0x7/0xb

Signed-off-by: Octavian Purdila 
Acked-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Remove *_bh from socket list lock.

2012-01-03T00:20:24+00:00

We don't need it anymore.

Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: fix bt_accept_dequeue() to work in process context

2011-12-22T16:02:08+00:00

No local_bh_disable is needed there once we run everything in process
context. The same goes for the replacement of bh_lock_sock() by
lock_sock().

Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Handle fragmented skbs in bt_sock_stream_recvmsg()

2011-09-27T21:16:07+00:00

ERTM reassembly will be more efficient when skbs are linked together
rather than copying every incoming data byte. The existing stream recv
function assumes skbs are linear, so it needs to know how to handle
fragments before reassembly is changed.

bt_sock_recvmsg() already handles fragmented skbs.

Signed-off-by: Mat Martineau 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Fix lost wakeups waiting for sock state change

2011-08-11T22:50:26+00:00

Fix race conditions which can cause lost wakeups while waiting
for sock state to change.

Signed-off-by: Peter Hurley 
Signed-off-by: Gustavo F. Padovan

Bluetooth: remove unnecessary call to hci_sock_cleanup

2011-02-26T01:36:58+00:00

hci_sock_cleanup is already called after the sock_err label.
It appears that we can drop this call.

Signed-off-by: Anand Gadiyar 
Signed-off-by: Gustavo F. Padovan

Bluetooth: fix checkpatch errors in af_bluetooth.c

2011-02-17T22:24:05+00:00

Signed-off-by: Gustavo F. Padovan