linux/net/bluetooth, branch v3.7.2

Revert "Bluetooth: Fix possible deadlock in SCO code"

2013-01-11T17:19:04Z

commit 0b27a4b97cb1874503c78453c0903df53c0c86b2 upstream. This reverts commit 269c4845d5b3627b95b1934107251bacbe99bb68. The commit was causing dead locks and NULL dereferences in the sco code: [28084.104013] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u:0H:7] [28084.104021] Modules linked in: btusb bluetooth ] _raw_spin_lock+0xd/0x10 [28084.104021] [] sco_conn_del+0x58/0x1b0 [bluetooth] [28084.104021] [] sco_connect_cfm+0xb9/0x2b0 [bluetooth] [28084.104021] [] hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth] [28084.104021] [] hci_event_packet+0x74d/0x2b40 [bluetooth] [28084.104021] [] ? __kfree_skb+0x3d/0x90 [28084.104021] [] ? kfree_skb+0x36/0x90 [28084.104021] [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] [28084.104021] [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] Reported-by: Chan-yeol Park Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman

Bluetooth: cancel power_on work when unregistering the device

2013-01-11T17:19:03Z

commit b9b5ef188e5a2222cfc16ef62a4703080750b451 upstream. We need to cancel the hci_power_on work in order to avoid it run when we try to free the hdev. [ 1434.201149] ------------[ cut here ]------------ [ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() [ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci _power_on+0x0/0x90 [ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G W 3.7.0-rc5-next- 20121112-sasha-00018-g2f4ce0e #127 [ 1434.210760] Call Trace: [ 1434.210760] [] ? debug_print_object+0x8e/0xb0 [ 1434.210760] [] warn_slowpath_common+0x87/0xb0 [ 1434.210760] [] warn_slowpath_fmt+0x41/0x50 [ 1434.210760] [] debug_print_object+0x8e/0xb0 [ 1434.210760] [] ? hci_dev_open+0x310/0x310 [ 1434.210760] [] ? _raw_spin_unlock_irqrestore+0x55/0xa0 [ 1434.210760] [] __debug_check_no_obj_freed+0xa5/0x230 [ 1434.210760] [] ? bt_host_release+0x10/0x20 [ 1434.210760] [] debug_check_no_obj_freed+0x15/0x20 [ 1434.210760] [] kfree+0x227/0x330 [ 1434.210760] [] bt_host_release+0x10/0x20 [ 1434.210760] [] device_release+0x65/0xc0 [ 1434.210760] [] kobject_cleanup+0x145/0x190 [ 1434.210760] [] kobject_release+0xd/0x10 [ 1434.210760] [] kobject_put+0x4c/0x60 [ 1434.210760] [] put_device+0x12/0x20 [ 1434.210760] [] hci_free_dev+0x24/0x30 [ 1434.210760] [] vhci_release+0x31/0x60 [ 1434.210760] [] __fput+0x122/0x250 [ 1434.210760] [] ? rcu_user_exit+0x9d/0xd0 [ 1434.210760] [] ____fput+0x9/0x10 [ 1434.210760] [] task_work_run+0xb2/0xf0 [ 1434.210760] [] do_notify_resume+0x77/0xa0 [ 1434.210760] [] int_signal+0x12/0x17 [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]--- Reported-by: Sasha Levin Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman

Bluetooth: Add missing lock nesting notation

2013-01-11T17:19:03Z

commit dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 upstream. 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: [] 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: [] 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 Signed-off-by: Gustavo Padovan Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix memory leak when removing a UUID

2012-11-09T15:45:37Z

When removing a UUID from the list in the remove_uuid() function we must also kfree the entry in addition to removing it from the list. Signed-off-by: Johan Hedberg Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan

Bluetooth: Notify about device registration before power on

2012-11-09T15:45:37Z

It is important that the monitor interface gets notified about a new device before its power on procedure has been started. For some reason that is no longer working as expected and the power on procedure runs first. It is safe to just notify about device registration and trigger the power on procedure afterwards. Signed-off-by: Marcel Holtmann Acked-by: Johan Hedberg Signed-off-by: Gustavo Padovan

Bluetooth: Fix error status when pairing fails

2012-11-09T15:45:37Z

When pairing fails due to wrong confirm value, the management layer doesn't report a proper error status. It sends MGMT_STATUS_CONNECT_FAILED instead of MGMT_STATUS_AUTH_FAILED. Most of management functions that receive a status as a parameter expects for it to be encoded as a HCI status. But when a SMP pairing fails, the SMP layer sends the SMP reason as the error status to the management layer. This commit maps all SMP reasons to HCI_ERROR_AUTH_FAILURE, which will be converted to MGMT_STATUS_AUTH_FAILED in the management layer. Reported-by: Claudio Takahasi Reviewed-by: João Paulo Rechi Vita Signed-off-by: Paulo Sérgio Signed-off-by: Gustavo Padovan

Bluetooth: Fix having bogus entries in mgmt_read_index_list reply

2012-11-09T15:45:37Z

The mgmt_read_index_list uses one loop to calculate the max needed size of its response with the help of an upper-bound of the controller count. The second loop is more strict as it checks for HCI_SETUP (which might have gotten set after the first loop) and could result in some indexes being skipped. Because of this the function needs to readjust the event length and index count after filling in the response array. Signed-off-by: Johan Hedberg Cc: stable@vger.kernel.org Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth

2012-10-15T18:34:23Z

userns: Properly print bluetooth socket uids

2012-10-12T20:16:47Z

With user namespace support enabled building bluetooth generated the warning. net/bluetooth/af_bluetooth.c: In function ‘bt_seq_show’: net/bluetooth/af_bluetooth.c:598:7: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 7 has type ‘kuid_t’ [-Wformat] Convert sock_i_uid from a kuid_t to a uid_t before printing, to avoid this problem. Reported-by: Fengguang Wu Cc: Masatake YAMATO Cc: Gustavo Padovan Signed-off-by: "Eric W. Biederman"

Bluetooth: SMP: Fix setting unknown auth_req bits

2012-10-12T09:55:20Z

When sending a pairing request or response we should not just blindly copy the value that the remote device sent. Instead we should at least make sure to mask out any unknown bits. This is particularly critical from the upcoming LE Secure Connections feature perspective as incorrectly indicating support for it (by copying the remote value) would cause a failure to pair with devices that support it. Signed-off-by: Johan Hedberg Cc: stable@kernel.org Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan