From 384943ec1bb462e410390ad8f108ff1474cd882d Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Fri, 8 May 2009 18:20:43 -0700
Subject: Bluetooth: Fix wrong module refcount when connection setup fails

The module refcount is increased by hci_dev_hold() call in hci_conn_add()
and decreased by hci_dev_put() call in del_conn(). In case the connection
setup fails, hci_dev_put() is never called.

Procedure to reproduce the issue:

  # hciconfig hci0 up
  # lsmod | grep btusb                   -> "used by" refcount = 1

  # hcitool cc <non-exisiting bdaddr>    -> will get timeout

  # lsmod | grep btusb                   -> "used by" refcount = 2
  # hciconfig hci0 down
  # lsmod | grep btusb                   -> "used by" refcount = 1
  # rmmod btusb                          -> ERROR: Module btusb is in use

The hci_dev_put() call got moved into del_conn() with the 2.6.25 kernel
to fix an issue with hci_dev going away before hci_conn. However that
change was wrong and introduced this problem.

When calling hci_conn_del() it has to call hci_dev_put() after freeing
the connection details. This handling should be fully symmetric. The
execution of del_conn() is done in a work queue and needs it own calls
to hci_dev_hold() and hci_dev_put() to ensure that the hci_dev stays
until the connection cleanup has been finished.

Based on a report by Bing Zhao <bzhao@marvell.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
---
 net/bluetooth/hci_conn.c  | 2 ++
 net/bluetooth/hci_sysfs.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 61309b26f27..85a1c6be2db 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -292,6 +292,8 @@ int hci_conn_del(struct hci_conn *conn)
 
 	hci_conn_del_sysfs(conn);
 
+	hci_dev_put(hdev);
+
 	return 0;
 }
 
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index a05d45eb3ba..4cc3624bd22 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -99,6 +99,8 @@ static void add_conn(struct work_struct *work)
 		BT_ERR("Failed to register connection device");
 		return;
 	}
+
+	hci_dev_hold(hdev);
 }
 
 /*
@@ -134,6 +136,7 @@ static void del_conn(struct work_struct *work)
 
 	device_del(&conn->dev);
 	put_device(&conn->dev);
+
 	hci_dev_put(hdev);
 }
 
-- 
cgit v1.2.3-18-g5258


From 1b0336bb36f88976f1210a65b62f6a3e9578ee7b Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 9 May 2009 12:04:08 -0700
Subject: Bluetooth: Don't use hci_acl_connect_cancel() for incoming
 connections

The connection setup phase takes around 2 seconds or longer and in
that time it is possible that the need for an ACL connection is no
longer present. If that happens then, the connection attempt will
be canceled.

This only applies to outgoing connections, but currently it can also
be triggered by incoming connection. Don't call hci_acl_connect_cancel()
on incoming connection since these have to be either accepted or rejected
in this state. Once they are successfully connected they need to be
fully disconnected anyway.

Also remove the wrong hci_acl_disconn() call for SCO and eSCO links
since at this stage they can't be disconnected either, because the
connection handle is still unknown.

Based on a report by Johan Hedberg <johan.hedberg@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
---
 net/bluetooth/hci_conn.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 85a1c6be2db..fa47d5d84f5 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -171,10 +171,8 @@ static void hci_conn_timeout(unsigned long arg)
 	switch (conn->state) {
 	case BT_CONNECT:
 	case BT_CONNECT2:
-		if (conn->type == ACL_LINK)
+		if (conn->type == ACL_LINK && conn->out)
 			hci_acl_connect_cancel(conn);
-		else
-			hci_acl_disconn(conn, 0x13);
 		break;
 	case BT_CONFIG:
 	case BT_CONNECTED:
-- 
cgit v1.2.3-18-g5258


From 3d7a9d1c7ee251a04095d43eec5a3f4ff3f710a8 Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 9 May 2009 12:09:21 -0700
Subject: Bluetooth: Don't trigger disconnect timeout for security mode 3
 pairing

A remote device in security mode 3 that tries to connect will require
the pairing during the connection setup phase. The disconnect timeout
is now triggered within 10 milliseconds and causes the pairing to fail.

If a connection is not fully established and a PIN code request is
received, don't trigger the disconnect timeout. The either successful
or failing connection complete event will make sure that the timeout
is triggered at the right time.

The biggest problem with security mode 3 is that many Bluetooth 2.0
device and before use a temporary security mode 3 for dedicated
bonding.

Based on a report by Johan Hedberg <johan.hedberg@nokia.com>

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
---
 net/bluetooth/hci_event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 4e7cb88e5da..184ba0a88ec 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1493,7 +1493,7 @@ static inline void hci_pin_code_request_evt(struct hci_dev *hdev, struct sk_buff
 	hci_dev_lock(hdev);
 
 	conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
-	if (conn) {
+	if (conn && conn->state == BT_CONNECTED) {
 		hci_conn_hold(conn);
 		conn->disc_timeout = HCI_PAIRING_TIMEOUT;
 		hci_conn_put(conn);
-- 
cgit v1.2.3-18-g5258