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>
When the l2cap info_timer is active the info_state will be set to
L2CAP_INFO_FEAT_MASK_REQ_SENT, and it will be unset after the timer is
deleted or timeout triggered.
Here in l2cap_conn_del only call del_timer_sync when the info_state is
set to L2CAP_INFO_FEAT_MASK_REQ_SENT.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Delete a possibly armed timer before kfree'ing the connection object.
Solves: http://lkml.org/lkml/2008/2/15/514
Reported-by:Quel Qun <kelk1@comcast.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
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>
In case the remote entity tries to negogiate retransmission or flow
control mode, reject it and fall back to basic mode.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Indicate the support for the L2CAP features mask value when the remote
entity tries to negotiate Bluetooth 1.2 specific features.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Bluetooth 1.2 specification introduced a specific features mask
value to interoperate with newer versions of the specification. So far
this piece of information was never needed, but future extensions will
rely on it. This patch adds a generic way to retrieve this information
only once per connection setup.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
After the change to the L2CAP configuration parameter handling the
global conf_mtu variable is no longer needed and so remove it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The parameters of the L2CAP output configuration might not be accepted
after the first configuration round. So only indicate a finished output
configuration when acceptable settings are provided.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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>
Since nobody uses it after we convert it to host-endian,
no need to do that at all. At that point l2cap is endian-clean.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
no code changes, just documenting existing types
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
We loop through psm values, calling __l2cap_get_sock_by_addr(psm, ...)
until we get NULL; then we set ->psm of our socket to htobs(psm).
IOW, we find unused psm value and put it into our socket. So far, so
good, but... __l2cap_get_sock_by_addr() compares its argument with
->psm of sockets. IOW, the entire thing works correctly only on
little-endian. On big-endian we'll get "no socket with such psm"
on the first iteration, since we won't find a socket with ->psm == 0x1001.
We will happily conclude that 0x1001 is unused and slap htobs(0x1001)
(i.e. 0x110) into ->psm of our socket. Of course, the next time around
the same thing will repeat and we'll just get a fsckload of sockets
with the same ->psm assigned.
Fix: pass htobs(psm) to __l2cap_get_sock_by_addr() there. All other
callers are already passing little-endian values and all places that
store something in ->psm are storing little-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The L2CAP configuration parameter handling was missing the support
for rejecting unknown options. The capability to reject unknown
options is mandatory since the Bluetooth 1.2 specification. This
patch implements its and also simplifies the parameter parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The L2CAP and HCI setsockopt() implementations have a small information
leak that makes it possible to leak kernel stack memory to userspace.
If the optlen parameter is 0, no data will be copied by copy_from_user(),
but the uninitialized stack buffer will be read and stored later. A call
to getsockopt() can now retrieve the leaked information.
To fix this problem the stack buffer given to copy_from_user() must be
initialized with the current settings.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
To clearly state the intent of copying from linear sk_buffs, _offset being a
overly long variant but interesting for the sake of saving some bytes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The PSM values below 0x1001 of L2CAP are reserved for well known
services. Restrict the possibility to bind them to privileged
users.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Any L2CAP connection in disconnecting state shall not response
to any further config requests from the remote side. So in case
such a request is received, ignore it.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When sending a positive config response it shall include the actual
MTU to be used on this channel. This differs from the Bluetooth 1.1
specification where it was enough to acknowledge the config request.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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>
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>
The Bluetooth L2CAP layer has 2 locks that are used in softirq context,
(one spinlock and one rwlock, where the softirq usage is readlock) but
where not all usages of the lock were _bh safe. The patch below corrects
this.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch is a small cleanup of the L2CAP source code. It makes some
coding style changes and moves some functions around to avoid forward
declarations.
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>
net: Use <linux/capability.h> where capable() is used.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
It also looks like there were 2 places where the test on sk_err was
missing from the event wait logic (in sk_stream_wait_connect and
sk_stream_wait_memory), while the rest of the sock_error() users look
to be doing the right thing. This version of the patch fixes those,
and cleans up a few places that were testing ->sk_err directly.
Signed-off-by: Benjamin LaHaise <benjamin.c.lahaise@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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>
- 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>
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>
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!
