History log of /net/bluetooth/rfcomm/sock.c
Revision Date Author Comments
093facf3634da1b0c2cc7ed106f1983da901bbab 14-Jul-2014 Vladimir Davydov <vdavydov@parallels.com> Bluetooth: never linger on process exit

If the current process is exiting, lingering on socket close will make
it unkillable, so we should avoid it.

Reproducer:

#include <sys/types.h>
#include <sys/socket.h>

#define BTPROTO_L2CAP 0
#define BTPROTO_SCO 2
#define BTPROTO_RFCOMM 3

int main()
{
int fd;
struct linger ling;

fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
//or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP);
//or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO);

ling.l_onoff = 1;
ling.l_linger = 1000000000;
setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));

return 0;
}

Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
676d23690fb62b5d51ba5d659935e9f7d9da9f8e 11-Apr-2014 David S. Miller <davem@davemloft.net> net: Fix use after free by removing length arg from sk_data_ready callbacks.

Several spots in the kernel perform a sequence like:

skb_queue_tail(&sk->s_receive_queue, skb);
sk->sk_data_ready(sk, skb->len);

But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up. So this skb->len access is potentially
to freed up memory.

Furthermore, the skb->len can be modified by the consumer so it is
possible that the value isn't accurate.

And finally, no actual implementation of this callback actually uses
the length argument. And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.

So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.

Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.

Signed-off-by: David S. Miller <davem@davemloft.net>
e8b1ab9e6d30394e0df3e4f60bf56c4dc9bf0863 26-Mar-2014 Johan Hedberg <johan.hedberg@intel.com> Bluetooth: Fix returning peer address in pending connect state

We should let user space request the peer address also in the pending
connect states, i.e. BT_CONNECT and BT_CONNECT2. There is existing user
space code that tries to do this and will fail without extending the set
of allowed states for the peer address information.

This patch adds the two states to the allowed ones in the L2CAP and
RFCOMM sock_getname functions, thereby preventing ENOTCONN from being
returned.

Reported-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Tested-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
b1765e7afe8710ef4366dc722cc5bd487eb07973 20-Feb-2014 Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Bluetooth: Fix channel check when binding RFCOMM sock

When binding RFCOMM socket with non-zero channel we're checking if
there is already any other socket which has the same channel number
assigned and then fail. This check does not consider situation where
we have another socket connected to remote device on given channel
number in which case we still should be able to bind local socket.

This patch changes __rfcomm_get_sock_by_addr() to return only sockets
in either BT_BOUND or BT_LISTEN states, also name is updated to better
describe what this function does now.

Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
35364c99d20edc7329843e2a6dad6851d77eafd7 29-Jan-2014 Johan Hedberg <johan.hedberg@intel.com> Bluetooth: Refuse peer RFCOMM address reading when not connected

When we're not connected the peer address information is undefined. This
patch fixes the remote address getting to return a proper error in case
the sate is anything else than BT_CONNECTED.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2c068e0b924c6fabd9a2ac59bc451b4b656cbae3 16-Jan-2014 Marcel Holtmann <marcel@holtmann.org> Bluetooth: Handle security level 4 for RFCOMM connections

With the introduction of security level 4, the RFCOMM sockets need to
be made aware of this new level. This change ensures that the pairing
requirements are set correctly for these connections.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
f3d3342602f8bcbf37d7c46641cb9bca7618eb1c 21-Nov-2013 Hannes Frederic Sowa <hannes@stressinduktion.org> net: rework recvmsg handler msg_name and msg_namelen logic

This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys->msg_namelen == 0)
msg->msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller <davem@davemloft.net>
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
60c7a3c9c77239d5a7430c42a2c796881716cca1 02-Nov-2013 Marcel Holtmann <marcel@holtmann.org> Bluetooth: Fix issue with RFCOMM getsockopt operation

The commit 94a86df01082557e2de45865e538d7fb6c46231c seem to have
uncovered a long standing bug that did not trigger so far.

BUG: unable to handle kernel paging request at 00000009dd503502
IP: [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: ath5k ath mac80211 cfg80211
CPU: 2 PID: 1459 Comm: bluetoothd Not tainted 3.11.0-133163-gcebd830 #2
Hardware name: System manufacturer System Product Name/P6T DELUXE V2, BIOS
1202 12/22/2010
task: ffff8803304106a0 ti: ffff88033046a000 task.ti: ffff88033046a000
RIP: 0010:[<ffffffff815b1868>] [<ffffffff815b1868>]
rfcomm_sock_getsockopt+0x128/0x200
RSP: 0018:ffff88033046bed8 EFLAGS: 00010246
RAX: 00000009dd503502 RBX: 0000000000000003 RCX: 00007fffa2ed5548
RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff88032fd37480
RBP: ffff88033046bf28 R08: 00007fffa2ed554c R09: ffff88032f5707d8
R10: 00007fffa2ed5548 R11: 0000000000000202 R12: ffff880330bbd000
R13: 00007fffa2ed5548 R14: 0000000000000003 R15: 00007fffa2ed554c
FS: 00007fc44cfac700(0000) GS:ffff88033fc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000009dd503502 CR3: 00000003304c2000 CR4: 00000000000007e0
Stack:
ffff88033046bf28 ffffffff815b0f2f ffff88033046bf18 0002ffff81105ef6
0000000600000000 ffff88032fd37480 0000000000000012 00007fffa2ed5548
0000000000000003 00007fffa2ed554c ffff88033046bf78 ffffffff814c0380
Call Trace:
[<ffffffff815b0f2f>] ? rfcomm_sock_setsockopt+0x5f/0x190
[<ffffffff814c0380>] SyS_getsockopt+0x60/0xb0
[<ffffffff815e0852>] system_call_fastpath+0x16/0x1b
Code: 02 00 00 00 0f 47 d0 4c 89 ef e8 74 13 cd ff 83 f8 01 19 c9 f7 d1 83 e1
f2 e9 4b ff ff ff 0f 1f 44 00 00 49 8b 84 24 70 02 00 00 <4c> 8b 30 4c 89 c0 e8
2d 19 cd ff 85 c0 49 89 d7 b9 f2 ff ff ff
RIP [<ffffffff815b1868>] rfcomm_sock_getsockopt+0x128/0x200
RSP <ffff88033046bed8>
CR2: 00000009dd503502

It triggers in the following segment of the code:

0x1313 is in rfcomm_sock_getsockopt (net/bluetooth/rfcomm/sock.c:743).
738
739 static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __user *optval, int __user *optlen)
740 {
741 struct sock *sk = sock->sk;
742 struct rfcomm_conninfo cinfo;
743 struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
744 int len, err = 0;
745 u32 opt;
746
747 BT_DBG("sk %p", sk);

The l2cap_pi(sk) is wrong here since it should have been rfcomm_pi(sk),
but that socket of course does not contain the low-level connection
details requested here.

Tracking down the actual offending commit, it seems that this has been
introduced when doing some L2CAP refactoring:

commit 8c1d787be4b62d2d1b6f04953eca4bcf7c839d44
Author: Gustavo F. Padovan <padovan@profusion.mobi>
Date: Wed Apr 13 20:23:55 2011 -0300

@@ -743,6 +743,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
struct sock *sk = sock->sk;
struct sock *l2cap_sk;
struct rfcomm_conninfo cinfo;
+ struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;
int len, err = 0;
u32 opt;

@@ -787,8 +788,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u

l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk;

- cinfo.hci_handle = l2cap_pi(l2cap_sk)->conn->hcon->handle;
- memcpy(cinfo.dev_class, l2cap_pi(l2cap_sk)->conn->hcon->dev_class, 3);
+ cinfo.hci_handle = conn->hcon->handle;
+ memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);

The l2cap_sk got accidentally mixed into the sk (which is RFCOMM) and
now causing a problem within getsocketopt() system call. To fix this,
just re-introduce l2cap_sk and make sure the right socket is used for
the low-level connection details.

Reported-by: Fabio Rossi <rossi.f@inwind.it>
Reported-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Tested-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
1120e4bfa5f9c28cb55d815ab3c6bed81dfc595c 18-Oct-2013 Marcel Holtmann <marcel@holtmann.org> Bluetooth: Use IS_ERR_OR_NULL for checking bt_debugfs

Make sure to use IS_ERR_OR_NULL for checking the existing of the root
debugfs dentry bt_debugfs.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
94a86df01082557e2de45865e538d7fb6c46231c 13-Oct-2013 Marcel Holtmann <marcel@holtmann.org> Bluetooth: Store RFCOMM address information in its own socket structure

The address information of RFCOMM sockets should be stored in its
own socket structure. Trying to generalize them is not helpful since
different transports have different address types.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
e793dcf082c847bd2b742c781252c20cbec37986 16-Sep-2013 Johan Hedberg <johan.hedberg@intel.com> Bluetooth: Fix waiting for clearing of BT_SK_SUSPEND flag

In the case of blocking sockets we should not proceed with sendmsg() if
the socket has the BT_SK_SUSPEND flag set. So far the code was only
ensuring that POLLOUT doesn't get set for non-blocking sockets using
poll() but there was no code in place to ensure that blocking sockets do
the right thing when writing to them.

This patch adds a new bt_sock_wait_ready helper function to sleep in the
sendmsg call if the BT_SK_SUSPEND flag is set, and wake up as soon as it
is unset. It also updates the L2CAP and RFCOMM sendmsg callbacks to take
advantage of this new helper function.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
b03166152f6da91cec8b66837b309dd3923ea536 05-Apr-2013 Al Viro <viro@zeniv.linux.org.uk> bluetooth: kill unused 'module' argument of bt_procfs_init()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
e11e0455c0d7d3d62276a0c55d9dfbc16779d691 07-Apr-2013 Mathias Krause <minipli@googlemail.com> Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()

If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
early with 0 without updating the possibly set msg_namelen member. This,
in turn, leads to a 128 byte kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_stream_recvmsg().

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
5e9d7f868f04106139a58212b860dcdc268ad3af 24-Feb-2013 David Herrmann <dh.herrmann@gmail.com> Bluetooth: discard bt_sock_unregister() errors

After we successfully registered a socket via bt_sock_register() there is
no reason to ever check the return code of bt_sock_unregister(). If
bt_sock_unregister() fails, it means the socket _is_ already unregistered
so we have what we want, don't we?

Also, to get bt_sock_unregister() to fail, another part of the kernel has
to unregister _our_ socket. This is sooo _wrong_ that it will break way
earlier than when we unregister our socket.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
b67bfe0d42cac56c512dd5da4b1b347a23f4b70a 28-Feb-2013 Sasha Levin <sasha.levin@oracle.com> hlist: drop the node parameter from iterators

I'm not sure why, but the hlist for each entry iterators were conceived

list_for_each_entry(pos, head, member)

The hlist ones were greedy and wanted an extra parameter:

hlist_for_each_entry(tpos, pos, head, member)

Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.

Besides the semantic patch, there was some manual work required:

- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.

The semantic patch which is mostly the work of Peter Senna Tschudin is here:

@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;

type T;
expression a,c,d,e;
identifier b;
statement S;
@@

-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>

[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 21-Nov-2012 Gustavo Padovan <gustavo.padovan@collabora.co.uk> Bluetooth: Add missing lock nesting notation

This patch fixes the following report, it happens when accepting rfcomm
connections:

[ 228.165378] =============================================
[ 228.165378] [ INFO: possible recursive locking detected ]
[ 228.165378] 3.7.0-rc1-00536-gc1d5dc4 #120 Tainted: G W
[ 228.165378] ---------------------------------------------
[ 228.165378] bluetoothd/1341 is trying to acquire lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
[ 228.165378]
[ 228.165378] but task is already holding lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
[ 228.165378]
[ 228.165378] other info that might help us debug this:
[ 228.165378] Possible unsafe locking scenario:
[ 228.165378]
[ 228.165378] CPU0
[ 228.165378] ----
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378]
[ 228.165378] *** DEADLOCK ***
[ 228.165378]
[ 228.165378] May be due to missing lock nesting notation

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
fcb73338ed531dcc00cb17ca76fe3e05f774e4e9 24-Sep-2012 Andrei Emeltchenko <andrei.emeltchenko@intel.com> Bluetooth: Use %pMR in sprintf/seq_printf instead of batostr

Instead of old unsafe batostr function use %pMR print specifier
for printing Bluetooth addresses in sprintf and seq_printf
statements.

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
6ed93dc6427d14cdfe0b272cc0a9ee4685ce9ad7 24-Sep-2012 Andrei Emeltchenko <andrei.emeltchenko@intel.com> Bluetooth: Use %pMR in debug instead of batostr

Instead of old unsafe batostr function use %pMR print specifier
for printing Bluetooth addresses in debug and error statements.

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
9344a972961d1a6d2c04d9008b13617bcb6ec2ef 15-Aug-2012 Mathias Krause <minipli@googlemail.com> Bluetooth: RFCOMM - Fix info leak via getsockname()

The RFCOMM code fails to initialize the trailing padding byte of struct
sockaddr_rc added for alignment. It that for leaks one byte kernel stack
via the getsockname() syscall. Add an explicit memset(0) before filling
the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9ad2de43f1aee7e7274a4e0d41465489299e344b 15-Aug-2012 Mathias Krause <minipli@googlemail.com> Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)

The RFCOMM code fails to initialize the key_size member of struct
bt_security before copying it to userland -- that for leaking one
byte kernel stack. Initialize key_size with 0 to avoid the info
leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
c6f5df16a2710e64090078dfbaa86c54a27c0874 25-Jul-2012 Masatake YAMATO <yamato@redhat.com> Bluetooth: Added /proc/net/rfcomm via bt_procfs_init()

Added /proc/net/rfcomm via bt_procfs_init().

Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
8c520a59927a5600973782505dbb750d985057c4 23-May-2012 Gustavo Padovan <gustavo.padovan@collabora.co.uk> Bluetooth: Remove unnecessary headers include

Most of the include were unnecessary or already included by some other
header.
Replace module.h by export.h where possible.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
c5daa683f2d3315cd766f550ef7d88bfca1671f4 16-May-2012 Gustavo Padovan <gustavo@padovan.org> Bluetooth: Create flags for bt_sk()

defer_setup and suspended are now flags into bt_sk().

Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
9ffc93f203c18a70623f21950f1dd473c9ec48cd 28-Mar-2012 David Howells <dhowells@redhat.com> Remove all #inclusions of asm/system.h

Remove all #inclusions of asm/system.h preparatory to splitting and killing
it. Performed with the following command:

perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`

Signed-off-by: David Howells <dhowells@redhat.com>
b5a30dda6598af216c070165ece6068f9f00f33a 21-Jan-2012 Octavian Purdila <tavi.purdila@gmail.com> Bluetooth: silence lockdep warning

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: [<c14970ea>] 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: [<c1498bf7>] 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] [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.738977] [<c13d35c1>] lock_sock_nested+0x58/0x68
<4>[ 1864.739411] [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
<4>[ 1864.739858] [<c13d06c3>] __sock_sendmsg+0x50/0x59
<4>[ 1864.740279] [<c13d0ea2>] sock_sendmsg+0x94/0xa8
<4>[ 1864.740687] [<c13d0ede>] kernel_sendmsg+0x28/0x37
<4>[ 1864.741106] [<c14969ca>] rfcomm_send_frame+0x30/0x38
<4>[ 1864.741542] [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
<4>[ 1864.741959] [<c1498447>] rfcomm_run+0x441/0xb52
<4>[ 1864.742365] [<c104f095>] kthread+0x63/0x68
<4>[ 1864.742742] [<c14d5182>] kernel_thread_helper+0x6/0xd
<4>[ 1864.743187]
<4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
<4>[ 1864.743667] [<c1061ada>] __lock_acquire+0x988/0xc00
<4>[ 1864.744100] [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.744519] [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
<4>[ 1864.744975] [<c14d303e>] mutex_lock_nested+0x2d/0x36
<4>[ 1864.745412] [<c14970ea>] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.745842] [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
<4>[ 1864.746288] [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
<4>[ 1864.746737] [<c13d275d>] sys_socketcall+0x1db/0x422
<4>[ 1864.747165] [<c14d42f0>] syscall_call+0x7/0xb

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
d22015aad40b4316f0f74c8e410debca44c3e6e2 21-Jan-2012 Octavian Purdila <tavi.purdila@gmail.com> Bluetooth: silence lockdep warning

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: [<c14970ea>] 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: [<c1498bf7>] 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] [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.738977] [<c13d35c1>] lock_sock_nested+0x58/0x68
<4>[ 1864.739411] [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
<4>[ 1864.739858] [<c13d06c3>] __sock_sendmsg+0x50/0x59
<4>[ 1864.740279] [<c13d0ea2>] sock_sendmsg+0x94/0xa8
<4>[ 1864.740687] [<c13d0ede>] kernel_sendmsg+0x28/0x37
<4>[ 1864.741106] [<c14969ca>] rfcomm_send_frame+0x30/0x38
<4>[ 1864.741542] [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
<4>[ 1864.741959] [<c1498447>] rfcomm_run+0x441/0xb52
<4>[ 1864.742365] [<c104f095>] kthread+0x63/0x68
<4>[ 1864.742742] [<c14d5182>] kernel_thread_helper+0x6/0xd
<4>[ 1864.743187]
<4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
<4>[ 1864.743667] [<c1061ada>] __lock_acquire+0x988/0xc00
<4>[ 1864.744100] [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.744519] [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
<4>[ 1864.744975] [<c14d303e>] mutex_lock_nested+0x2d/0x36
<4>[ 1864.745412] [<c14970ea>] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.745842] [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
<4>[ 1864.746288] [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
<4>[ 1864.746737] [<c13d275d>] sys_socketcall+0x1db/0x422
<4>[ 1864.747165] [<c14d42f0>] syscall_call+0x7/0xb

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
95ca83f42fb5f5bf789b514635f79242afe555d1 27-Dec-2011 Gustavo F. Padovan <padovan@profusion.mobi> Bluetooth: Fix context in rfcomm_sock_lock

Code now run in process context, does not need to disable interrupt
anymore.

Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
262038fcb2a50e9b5553243452918fda08cdf83d 01-Nov-2011 Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Bluetooth: make use sk_priority to priritize RFCOMM packets

Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
6230c9b4f8957c8938ee4cf2d03166d3c2dc89de 07-Oct-2011 Paul Moore <pmoore@redhat.com> bluetooth: Properly clone LSM attributes to newly created child connections

The Bluetooth stack has internal connection handlers for all of the various
Bluetooth protocols, and unfortunately, they are currently lacking the LSM
hooks found in the core network stack's connection handlers. I say
unfortunately, because this can cause problems for users who have have an
LSM enabled and are using certain Bluetooth devices. See one problem
report below:

* http://bugzilla.redhat.com/show_bug.cgi?id=741703

In order to keep things simple at this point in time, this patch fixes the
problem by cloning the parent socket's LSM attributes to the newly created
child socket. If we decide we need a more elaborate LSM marking mechanism
for Bluetooth (I somewhat doubt this) we can always revisit this decision
in the future.

Reported-by: James M. Cape <jcape@ignore-your.tv>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
950e2d51e866623e4c360280aa63b85ab66d3403 24-Jul-2011 Peter Hurley <peter@hurleysoftware.com> Bluetooth: rfcomm: Fix lost wakeups waiting to accept socket

Fix race conditions which can cause lost wakeups (or missed
signals) while waiting to accept an rfcomm socket connection.

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
8d03e971cf403305217b8e62db3a2e5ad2d6263f 12-May-2011 Filip Palian <s3810@pjwstk.edu.pl> Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.

Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding
byte each. This byte in "cinfo" is copied to userspace uninitialized.

Signed-off-by: Filip Palian <filip.palian@pjwstk.edu.pl>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
d0fad89da9801b3945d2ee7243ecbc75b3da6f09 13-May-2011 Stephen Boyd <sboyd@codeaurora.org> Bluetooth: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning

Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following
warning:

In function 'copy_from_user',
inlined from 'rfcomm_sock_setsockopt' at
net/bluetooth/rfcomm/sock.c:705:
arch/x86/include/asm/uaccess_64.h:65:
warning: call to 'copy_from_user_overflow' declared with
attribute warning: copy_from_user() buffer size is not provably
correct

presumably due to buf_size being signed causing GCC to fail to
see that buf_size can't become negative.

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
75fde9ee1bca0c0c004aadaebdedf17370f93f18 20-May-2011 David Miller <davem@davemloft.net> Bluetooth: Kill set but not used variable 'l2cap_sk' in rfcomm_sock_getsockopt_old()

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
8c1d787be4b62d2d1b6f04953eca4bcf7c839d44 14-Apr-2011 Gustavo F. Padovan <padovan@profusion.mobi> 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>
285b4e90318dcf421a00b2ac3fe8ab713f3281e3 01-Dec-2010 Andrei Emeltchenko <andrei.emeltchenko@nokia.com> 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>
eeb366564be7c311b31c70821d18a43a8a57f9bc 01-Nov-2010 Gustavo F. Padovan <padovan@profusion.mobi> Bluetooth: Get rid of __rfcomm_get_sock_by_channel()

rfcomm_get_sock_by_channel() was the only user of this function, so I merged
both into rfcomm_get_sock_by_channel(). The socket lock now should be hold
outside of rfcomm_get_sock_by_channel() once we hold and release it inside the
same function now.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
3d7d01dffec4a6757ed1e3182f01c7ef5caa2539 08-Sep-2010 Mat Martineau <mathewm@codeaurora.org> Bluetooth: Use common SOCK_STREAM receive code in RFCOMM

To reduce code duplication, have rfcomm_sock_recvmsg() call
bt_sock_stream_recvmsg(). The common bt_sock_stream_recvmsg()
code is nearly identical, with the RFCOMM-specific functionality
for deferred setup and connection unthrottling left in
rfcomm_sock_recvmsg().

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
fad003b6c8e3d944d4453fd569b0702ef1af82b3 14-Aug-2010 Gustavo F. Padovan <padovan@profusion.mobi> Bluetooth: Fix inconsistent lock state with RFCOMM

When receiving a rfcomm connection with the old dund deamon a
inconsistent lock state happens. That's because interrupts were already
disabled by l2cap_conn_start() when rfcomm_sk_state_change() try to lock
the spin_lock.

As result we may have a inconsistent lock state for l2cap_conn_start()
after rfcomm_sk_state_change() calls bh_lock_sock() and disable interrupts
as well.

[ 2833.151999]
[ 2833.151999] =================================
[ 2833.151999] [ INFO: inconsistent lock state ]
[ 2833.151999] 2.6.36-rc3 #2
[ 2833.151999] ---------------------------------
[ 2833.151999] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[ 2833.151999] krfcommd/2306 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 2833.151999] (slock-AF_BLUETOOTH){+.?...}, at: [<ffffffffa00bcb56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999] {IN-SOFTIRQ-W} state was registered at:
[ 2833.151999] [<ffffffff81094346>] __lock_acquire+0x5b6/0x1560
[ 2833.151999] [<ffffffff8109534a>] lock_acquire+0x5a/0x70
[ 2833.151999] [<ffffffff81392b6c>] _raw_spin_lock+0x2c/0x40
[ 2833.151999] [<ffffffffa00a5092>] l2cap_conn_start+0x92/0x640 [l2cap]
[ 2833.151999] [<ffffffffa00a6a3f>] l2cap_sig_channel+0x6bf/0x1320 [l2cap]
[ 2833.151999] [<ffffffffa00a9173>] l2cap_recv_frame+0x133/0x770 [l2cap]
[ 2833.151999] [<ffffffffa00a997b>] l2cap_recv_acldata+0x1cb/0x390 [l2cap]
[ 2833.151999] [<ffffffffa000db4b>] hci_rx_task+0x2ab/0x450 [bluetooth]
[ 2833.151999] [<ffffffff8106b22b>] tasklet_action+0xcb/0xe0
[ 2833.151999] [<ffffffff8106b91e>] __do_softirq+0xae/0x150
[ 2833.151999] [<ffffffff8102bc0c>] call_softirq+0x1c/0x30
[ 2833.151999] [<ffffffff8102ddb5>] do_softirq+0x75/0xb0
[ 2833.151999] [<ffffffff8106b56d>] irq_exit+0x8d/0xa0
[ 2833.151999] [<ffffffff8104484b>] smp_apic_timer_interrupt+0x6b/0xa0
[ 2833.151999] [<ffffffff8102b6d3>] apic_timer_interrupt+0x13/0x20
[ 2833.151999] [<ffffffff81029dfa>] cpu_idle+0x5a/0xb0
[ 2833.151999] [<ffffffff81381ded>] rest_init+0xad/0xc0
[ 2833.151999] [<ffffffff817ebc4d>] start_kernel+0x2dd/0x2e8
[ 2833.151999] [<ffffffff817eb2e6>] x86_64_start_reservations+0xf6/0xfa
[ 2833.151999] [<ffffffff817eb3ce>] x86_64_start_kernel+0xe4/0xeb
[ 2833.151999] irq event stamp: 731
[ 2833.151999] hardirqs last enabled at (731): [<ffffffff8106b762>] local_bh_enable_ip+0x82/0xe0
[ 2833.151999] hardirqs last disabled at (729): [<ffffffff8106b93e>] __do_softirq+0xce/0x150
[ 2833.151999] softirqs last enabled at (730): [<ffffffff8106b96e>] __do_softirq+0xfe/0x150
[ 2833.151999] softirqs last disabled at (711): [<ffffffff8102bc0c>] call_softirq+0x1c/0x30
[ 2833.151999]
[ 2833.151999] other info that might help us debug this:
[ 2833.151999] 2 locks held by krfcommd/2306:
[ 2833.151999] #0: (rfcomm_mutex){+.+.+.}, at: [<ffffffffa00bb744>] rfcomm_run+0x174/0xb20 [rfcomm]
[ 2833.151999] #1: (&(&d->lock)->rlock){+.+...}, at: [<ffffffffa00b9223>] rfcomm_dlc_accept+0x53/0x100 [rfcomm]
[ 2833.151999]
[ 2833.151999] stack backtrace:
[ 2833.151999] Pid: 2306, comm: krfcommd Tainted: G W 2.6.36-rc3 #2
[ 2833.151999] Call Trace:
[ 2833.151999] [<ffffffff810928e1>] print_usage_bug+0x171/0x180
[ 2833.151999] [<ffffffff810936c3>] mark_lock+0x333/0x400
[ 2833.151999] [<ffffffff810943ca>] __lock_acquire+0x63a/0x1560
[ 2833.151999] [<ffffffff810948b5>] ? __lock_acquire+0xb25/0x1560
[ 2833.151999] [<ffffffff8109534a>] lock_acquire+0x5a/0x70
[ 2833.151999] [<ffffffffa00bcb56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999] [<ffffffff81392b6c>] _raw_spin_lock+0x2c/0x40
[ 2833.151999] [<ffffffffa00bcb56>] ? rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999] [<ffffffffa00bcb56>] rfcomm_sk_state_change+0x46/0x170 [rfcomm]
[ 2833.151999] [<ffffffffa00b9239>] rfcomm_dlc_accept+0x69/0x100 [rfcomm]
[ 2833.151999] [<ffffffffa00b9a49>] rfcomm_check_accept+0x59/0xd0 [rfcomm]
[ 2833.151999] [<ffffffffa00bacab>] rfcomm_recv_frame+0x9fb/0x1320 [rfcomm]
[ 2833.151999] [<ffffffff813932bb>] ? _raw_spin_unlock_irqrestore+0x3b/0x60
[ 2833.151999] [<ffffffff81093acd>] ? trace_hardirqs_on_caller+0x13d/0x180
[ 2833.151999] [<ffffffff81093b1d>] ? trace_hardirqs_on+0xd/0x10
[ 2833.151999] [<ffffffffa00bb7f1>] rfcomm_run+0x221/0xb20 [rfcomm]
[ 2833.151999] [<ffffffff813905e7>] ? schedule+0x287/0x780
[ 2833.151999] [<ffffffffa00bb5d0>] ? rfcomm_run+0x0/0xb20 [rfcomm]
[ 2833.151999] [<ffffffff81081026>] kthread+0x96/0xa0
[ 2833.151999] [<ffffffff8102bb14>] kernel_thread_helper+0x4/0x10
[ 2833.151999] [<ffffffff813936bc>] ? restore_args+0x0/0x30
[ 2833.151999] [<ffffffff81080f90>] ? kthread+0x0/0xa0
[ 2833.151999] [<ffffffff8102bb10>] ? kernel_thread_helper+0x0/0x10

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
2f8362afcd2da8b313ec3cc04a50af19d3592972 24-Jul-2010 Gustavo F. Padovan <padovan@profusion.mobi> Bluetooth: Add __init and __exit marks to RFCOMM

Those annotation save memory and space on the binary. __init code is
discarded just after execute and __exit code is discarded if the module
is built into the kernel image or unload of modules is not allowed.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
aa395145165cb06a0d0885221bbe0ce4a564391d 20-Apr-2010 Eric Dumazet <eric.dumazet@gmail.com> net: sk_sleep() helper

Define a new function to return the waitqueue of a "struct sock".

static inline wait_queue_head_t *sk_sleep(struct sock *sk)
{
return sk->sk_sleep;
}

Change all read occurrences of sk_sleep by a call to this function.

Needed for a future RCU conversion. sk_sleep wont be a field directly
available.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
6503d96168f891ffa3b70ae6c9698a1a722025a0 01-Apr-2010 Changli Gao <xiaosuo@gmail.com> net: check the length of the socket address passed to connect(2)

check the length of the socket address passed to connect(2).

Check the length of the socket address passed to connect(2). If the
length is invalid, -EINVAL will be returned.

Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
net/bluetooth/l2cap.c | 3 ++-
net/bluetooth/rfcomm/sock.c | 3 ++-
net/bluetooth/sco.c | 3 ++-
net/can/bcm.c | 3 +++
net/ieee802154/af_ieee802154.c | 3 +++
net/ipv4/af_inet.c | 5 +++++
net/netlink/af_netlink.c | 3 +++
7 files changed, 20 insertions(+), 3 deletions(-)
Signed-off-by: David S. Miller <davem@davemloft.net>
aef7d97cc604309b66f6f45cce02cd734934cd4e 21-Mar-2010 Marcel Holtmann <marcel@holtmann.org> 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>
101545f6fef4a0a3ea8daf0b5b880df2c6a92a69 15-Mar-2010 Marcel Holtmann <marcel@holtmann.org> 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>
28812fe11a21826ba4c97c6c7971a619987cd912 05-Jan-2010 Andi Kleen <andi@firstfloor.org> 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>
3f378b684453f2a028eda463ce383370545d9cc9 06-Nov-2009 Eric Paris <eparis@redhat.com> net: pass kern to net_proto_family create function

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>
3b885787ea4112eaa80945999ea0901bf742707f 12-Oct-2009 Neil Horman <nhorman@tuxdriver.com> net: Generalize socket rx gap / receive queue overflow cmsg

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>
ec1b4cf74c81bfd0fbe5bf62bafc86c45917e72f 05-Oct-2009 Stephen Hemminger <shemminger@vyatta.com> net: mark net_proto_ops as const

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>
b7058842c940ad2c08dd829b21e5c92ebe3b8758 01-Oct-2009 David S. Miller <davem@davemloft.net> net: Make setsockopt() optlen be unsigned.

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>
af0d3b103bcfa877343ee338de12002cd50c9ee5 03-Aug-2009 Dave Young <hidave.darkstar@gmail.com> 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>
0588d94fd7e414367a7ae517569d2222441c255f 16-Jan-2009 Marcel Holtmann <marcel@holtmann.org> Bluetooth: Restrict application of socket options

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>
9f2c8a03fbb3048cf38b158f87aa0c3c09bca084 15-Jan-2009 Marcel Holtmann <marcel@holtmann.org> 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>
bb23c0ab824653be4aa7dfca15b07b3059717004 15-Jan-2009 Marcel Holtmann <marcel@holtmann.org> 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>
d58daf42d29a3a4a4d4be46cf47ceee096789680 15-Jan-2009 Marcel Holtmann <marcel@holtmann.org> Bluetooth: Preparation for usage of SOL_BLUETOOTH

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>
91aa35a5aa3540223066bf6b51c935418c63a35d 15-Jan-2009 Victor Shcherbatyuk <victor.shcherbatyuk@tomtom.com> Bluetooth: Fix issue with return value of rfcomm_sock_sendmsg()

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>
e19caae7177fcc732ae1b47135e39f577352adb2 09-Dec-2008 David S. Miller <davem@davemloft.net> bluetooth: Fix unused var warning properly in rfcomm_sock_ioctl().

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>
6cf1a0f856bcb5423bfb4121b2dfeaa3ba7b1ff2 09-Dec-2008 David S. Miller <davem@davemloft.net> bluetooth: Fix rfcomm_sock_ioctl() build failure with debugging enabled.

It's 'sock' not 'sk'.

Signed-off-by: David S. Miller <davem@davemloft.net>
a418b893a6af11ae73c762ed5b76c1bad6dc19d8 30-Nov-2008 Marcel Holtmann <marcel@holtmann.org> 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>
45555c0ed436b8b06eeaa5c524a3377e6d24fb45 26-Nov-2008 Ingo Molnar <mingo@elte.hu> bluetooth: fix warning in net/bluetooth/rfcomm/sock.c

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>
3241ad820dbb172021e0268b5611031991431626 14-Jul-2008 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCO

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>
77db1980565626471a980f0d2d17299e4bd5e7a5 14-Jul-2008 Marcel Holtmann <marcel@holtmann.org> [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>
0b040829952d84bf2a62526f0e24b624e0699447 11-Jun-2008 Adrian Bunk <bunk@kernel.org> 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>
d5fb2962c6157495e1365e4f30568ed3830d35a7 29-Mar-2008 Robert P. J. Day <rpjday@crashcourse.ca> bluetooth: replace deprecated RW_LOCK_UNLOCKED macros

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>
3b1e0a655f8eba44ab1ee2a1068d169ccfb853b9 25-Mar-2008 YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> [NET] NETNS: Omit sock->sk_net without CONFIG_NET_NS.

Introduce per-sock inlines: sock_net(), sock_net_set()
and per-inet_timewait_sock inlines: twsk_net(), twsk_net_set().
Without CONFIG_NET_NS, no namespace other than &init_net exists.
Let's explicitly define them to help compiler optimizations.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
6257ff2177ff02d7f260a7a501876aa41cb9a9f6 01-Nov-2007 Pavel Emelyanov <xemul@openvz.org> [NET]: Forget the zero_it argument of sk_alloc()

Finally, the zero_it argument can be completely removed from
the callers and from the function prototype.

Besides, fix the checkpatch.pl warnings about using the
assignments inside if-s.

This patch is rather big, and it is a part of the previous one.
I splitted it wishing to make the patches more readable. Hope
this particular split helped.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
1b8d7ae42d02e483ad94035cca851e4f7fbecb40 09-Oct-2007 Eric W. Biederman <ebiederm@xmission.com> [NET]: Make socket creation namespace safe.

This patch passes in the namespace a new socket should be created in
and has the socket code do the appropriate reference counting. By
virtue of this all socket create methods are touched. In addition
the socket create methods are modified so that they will fail if
you attempt to create a socket in a non-default network namespace.

Failing if we attempt to create a socket outside of the default
network namespace ensures that as we incrementally make the network stack
network namespace aware we will not export functionality that someone
has not audited and made certain is network namespace safe.
Allowing us to partially enable network namespaces before all of the
exotic protocols are supported.

Any protocol layers I have missed will fail to compile because I now
pass an extra parameter into the socket creation code.

[ Integrated AF_IUCV build fixes from Andrew Morton... -DaveM ]

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
8e87d14255acffeee36873de226dc25c11b5f46d 09-Feb-2007 YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> [NET] BLUETOOTH: Fix whitespace errors.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
4d6a2188bd456969f52c03edf1988de90f08d9f5 08-Jan-2007 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Fix uninitialized return value for RFCOMM sendmsg()

When calling send() with a zero length parameter on a RFCOMM socket
it returns a positive value. In this rare case the variable err is
used uninitialized and unfortunately its value is returned.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
74da626a1098640ddc40c0e3481c0cd41e8ec1e9 15-Oct-2006 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Add locking for bt_proto array manipulation

The bt_proto array needs to be protected by some kind of locking to
prevent a race condition between bt_sock_create and bt_sock_register.

And in addition all calls to sk_alloc need to be made GFP_ATOMIC now.

Signed-off-by: Masatake YAMATO <jet@gyve.org>
Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
df5c37ea9a3820a9515d8204450aec00f48f8f88 15-Oct-2006 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Handle return values from driver core functions

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>
a91f2e396f5b32b21d842b4757bc8de5e88eac66 03-Jul-2006 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Use real devices for host controllers

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>
6ab3d5624e172c553004ecc862bfeac16d9d68b7 30-Jun-2006 Jörn Engel <joern@wohnheim.fh-wedel.de> Remove obsolete #include <linux/config.h>

Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
90ddc4f0470427df306f308ad03db6b6b21644b8 22-Dec-2005 Eric Dumazet <dada1@cosmosbay.com> [NET]: move struct proto_ops to const

I noticed that some of 'struct proto_ops' used in the kernel may share
a cache line used by locks or other heavily modified data. (default
linker alignement is 32 bytes, and L1_CACHE_LINE is 64 or 128 at
least)

This patch makes sure a 'struct proto_ops' can be declared as const,
so that all cpus can share all parts of it without false sharing.

This is not mandatory : a driver can still use a read/write structure
if it needs to (and eventually a __read_mostly)

I made a global stubstitute to change all existing occurences to make
them const.

This should reduce the possibility of false sharing on SMP, and
speedup some socket system calls.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
be9d122730c878baafe11e70d1436faac229f2fc 08-Nov-2005 Marcel Holtmann <marcel@holtmann.org> [Bluetooth]: Remove the usage of /proc completely

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>
dd0fc66fb33cd610bc1a5db8a5e232d34879b4d7 07-Oct-2005 Al Viro <viro@ftp.linux.org.uk> [PATCH] gfp flags annotations - part 1

- 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>
354d28d5f8546e115ebaae9311897f0bc4b6a8d4 13-Sep-2005 Marcel Holtmann <marcel@holtmann.org> [Bluetooth] Prevent RFCOMM connections through the RAW socket

This patch adds additional checks to prevent RFCOMM connections be
established through the RAW socket interface.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2eb25a6c34504254760e67172f7518d6bfdd7676 10-Aug-2005 Victor Fusco <victor@cetuc.puc-rio.br> [Bluetooth]: Fix sparse warnings (__nocast type)

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>
b03efcfb2180289718991bb984044ce6c5b7d1b0 08-Jul-2005 David S. Miller <davem@davemloft.net> [NET]: Transform skb_queue_len() binary tests into skb_queue_empty()

This is part of the grand scheme to eliminate the qlen
member of skb_queue_head, and subsequently remove the
'list' member of sk_buff.

Most users of skb_queue_len() want to know if the queue is
empty or not, and that's trivially done with skb_queue_empty()
which doesn't use the skb_queue_head->qlen member and instead
uses the queue list emptyness as the test.

Signed-off-by: David S. Miller <davem@davemloft.net>
5523662c4cd585b892811d7bb3e25d9a787e19b3 26-Apr-2005 Al Viro <viro@parcelfarce.linux.theplanet.co.uk> [NET]: kill gratitious includes of major.h

A lot of places in there are including major.h for no reason
whatsoever. Removed. And yes, it still builds.

The history of that stuff is often amusing. E.g. for net/core/sock.c
the story looks so, as far as I've been able to reconstruct it: we used to
need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need had
disappeared, along with register_chrdev(SOCKET_MAJOR, "socket", &net_fops)
in sock_init(). Include had not. When 1.2 -> 1.3 reorg of net/* had moved
a lot of stuff from net/socket.c to net/core/sock.c, this crap had followed...

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
b453257f057b834fdf9f4a6ad6133598b79bd982 26-Apr-2005 Al Viro <viro@www.linux.org.uk> [PATCH] kill gratitious includes of major.h under net/*

A lot of places in there are including major.h for no reason whatsoever.
Removed. And yes, it still builds.

The history of that stuff is often amusing. E.g. for net/core/sock.c
the story looks so, as far as I've been able to reconstruct it: we used
to need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need
had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
&net_fops) in sock_init(). Include had not. When 1.2 -> 1.3 reorg of
net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
this crap had followed...

Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 17-Apr-2005 Linus Torvalds <torvalds@ppc970.osdl.org> Linux-2.6.12-rc2

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!