From 384943ec1bb462e410390ad8f108ff1474cd882d Mon Sep 17 00:00:00 2001 From: Marcel Holtmann 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 -> 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 Signed-off-by: Marcel Holtmann Tested-by: Bing Zhao --- net/bluetooth/hci_conn.c | 2 ++ net/bluetooth/hci_sysfs.c | 3 +++ 2 files changed, 5 insertions(+) (limited to 'net') diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 61309b2..85a1c6b 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 a05d45e..4cc3624 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.1 From 1b0336bb36f88976f1210a65b62f6a3e9578ee7b Mon Sep 17 00:00:00 2001 From: Marcel Holtmann 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 Signed-off-by: Marcel Holtmann Tested-by: Johan Hedberg --- net/bluetooth/hci_conn.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'net') diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 85a1c6b..fa47d5d 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.1 From 3d7a9d1c7ee251a04095d43eec5a3f4ff3f710a8 Mon Sep 17 00:00:00 2001 From: Marcel Holtmann 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 Signed-off-by: Marcel Holtmann Tested-by: Johan Hedberg --- net/bluetooth/hci_event.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'net') diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 4e7cb88..184ba0a 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.1