linux-toradex.git/net/bluetooth/rfcomm, branch tegra

Bluetooth: Drop rfcomm session reference only once for incoming session

2012-01-20T00:15:16+00:00

Move decision to drop reference for incoming session to
rfcomm_session_close to get more clear
rfcomm_session_hold()/rfcomm_session_put() pairs.

Rebase by: Jaikumar Ganesh 

Signed-off-by: Ville Tervo 
Signed-off-by: Jaikumar Ganesh 
(cherry picked from commit dacd12646bbe15c98ab2b74b266092271a41d278)

Change-Id: I6b9374bb732d4f9706a65be19f8dbfddbe1de2df
Signed-off-by: Nagarjuna Kristam 
Reviewed-on: http://git-master/r/75236
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Bharat Nihalani 
Reviewed-by: Rakesh Goyal

Bluetooth: Do not attempt to send dlci disconnect when in BT_CONFIG.

2011-12-01T05:38:12+00:00

This fixes a bug where shutdown() and close() on a rfcomm socket during ACL
connection would not cause HCI Create Connection Cancel.

Signed-off-by: Nick Pelly

bluetooth: Properly clone LSM attributes to newly created child connections

2011-10-19T03:36:43+00:00

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 
Signed-off-by: Paul Moore 
Acked-by: James Morris 
Signed-off-by: David S. Miller

Bluetooth: rfcomm: Fix lost wakeups waiting to accept socket

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

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

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

Bluetooth: rfcomm: Remove unnecessary krfcommd event

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

Removed superfluous event handling which was used to signal
that the rfcomm kthread had been woken. This appears to have been
used to prevent lost wakeups. Correctly ordering when the task
state is set to TASK_INTERRUPTIBLE is sufficient to prevent lost wakeups.

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

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

Merge master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-2.6

2011-06-09T19:33:54+00:00

Conflicts:
	net/bluetooth/rfcomm/sock.c

Bluetooth: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning

2011-06-09T18:30:01+00:00

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 
Cc: Gustavo F. Padovan 
Signed-off-by: Stephen Boyd 
Signed-off-by: Gustavo F. Padovan

Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.

2011-06-09T18:30:01+00:00

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 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Kill set but not used variable 'l2cap_sk' in rfcomm_sock_getsockopt_old()

2011-06-08T19:58:15+00:00

Signed-off-by: David S. Miller 
Signed-off-by: Gustavo F. Padovan

Bluetooth: Double check sec req for pre 2.1 device

2011-05-11T17:56:28+00:00

In case of pre v2.1 devices authentication request will return
success immediately if the link key already exists without any
authentication process.

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

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

Signed-off-by: Waldemar Rymarkiewicz 
Signed-off-by: Gustavo F. Padovan