[PATCH v2 0/4] Bluetooth: Improve retrying of connection attempts

[PATCH v2 0/4] Bluetooth: Improve retrying of connection attempts

[Jonas Dreßler]

Since commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect
requests"), the kernel supports trying to connect again in case the
bluetooth card is busy and fails to connect.

The logic that should handle this became a bit spotty over time, and also
cards these days appear to fail with more errors than just "Command
Disallowed".

This series refactores the handling of concurrent connection requests
by serializing all "Create Connection" commands for ACL connections
similar to how we do it for LE connections.

---

v1: https://lore.kernel.org/linux-bluetooth/20240102185933.64179-1-verdre@v0yd.nl/
v2:
  - Move to using hci_sync queue for "Create Connection" and therefore
    always serialize those requests.
  - Follow commit message style better and properly cite patches

Jonas Dreßler (4):
  Bluetooth: Remove superfluous call to hci_conn_check_pending()
  Bluetooth: hci_event: Use HCI error defines instead of magic values
  Bluetooth: hci_conn: Only do ACL connections sequentially
  Bluetooth: Remove pending ACL connection attempts

 include/net/bluetooth/hci.h      |  3 ++
 include/net/bluetooth/hci_core.h |  1 -
 net/bluetooth/hci_conn.c         | 51 ++++++++++++++++----------------
 net/bluetooth/hci_event.c        | 29 +++++-------------
 4 files changed, 35 insertions(+), 49 deletions(-)

-- 
2.43.0

[PATCH v2 1/4] Bluetooth: Remove superfluous call to hci_conn_check_pending()

[Jonas Dreßler]

The "pending connections" feature was originally introduced with commit
4c67bc74f016 ("[Bluetooth] Support concurrent connect requests") and
6bd57416127e ("[Bluetooth] Handling pending connect attempts after
inquiry") to handle controllers supporting only a single connection request
at a time. Later things were extended to also cancel ongoing inquiries on
connect() with commit 89e65975fea5 ("Bluetooth: Cancel Inquiry before
Create Connection").

With commit a9de9248064b ("[Bluetooth] Switch from OGF+OCF to using only
opcodes"), hci_conn_check_pending() was introduced as a helper to
consolidate a few places where we check for pending connections (indicated
by the BT_CONNECT2 flag) and then try to connect.

This refactoring commit also snuck in two more calls to
hci_conn_check_pending():

- One is in the failure callback of hci_cs_inquiry(), this one probably
makes sense: If we send an "HCI Inquiry" command and then immediately
after a "Create Connection" command, the "Create Connection" command might
fail before the "HCI Inquiry" command, and then we want to retry the
"Create Connection" on failure of the "HCI Inquiry".

- The other added call to hci_conn_check_pending() is in the event handler
for the "Remote Name" event, this seems unrelated and is possibly a
copy-paste error, so remove that one.

Fixes: a9de9248064b ("[Bluetooth] Switch from OGF+OCF to using only opcodes")
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
---
 net/bluetooth/hci_event.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 31ca320ce..13396329f 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3538,8 +3538,6 @@ static void hci_remote_name_evt(struct hci_dev *hdev, void *data,
 
 	bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
 
-	hci_conn_check_pending(hdev);
-
 	hci_dev_lock(hdev);
 
 	conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
-- 
2.43.0

[PATCH v2 2/4] Bluetooth: hci_event: Use HCI error defines instead of magic values

[Jonas Dreßler]

We have error defines already, so let's use them.

Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
---
 include/net/bluetooth/hci.h | 2 ++
 net/bluetooth/hci_event.c   | 8 ++++----
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 111e8f8e5..fef723afd 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -641,6 +641,7 @@ enum {
 #define HCI_ERROR_PIN_OR_KEY_MISSING	0x06
 #define HCI_ERROR_MEMORY_EXCEEDED	0x07
 #define HCI_ERROR_CONNECTION_TIMEOUT	0x08
+#define HCI_ERROR_COMMAND_DISALLOWED	0x0c
 #define HCI_ERROR_REJ_LIMITED_RESOURCES	0x0d
 #define HCI_ERROR_REJ_BAD_ADDR		0x0f
 #define HCI_ERROR_INVALID_PARAMETERS	0x12
@@ -649,6 +650,7 @@ enum {
 #define HCI_ERROR_REMOTE_POWER_OFF	0x15
 #define HCI_ERROR_LOCAL_HOST_TERM	0x16
 #define HCI_ERROR_PAIRING_NOT_ALLOWED	0x18
+#define HCI_ERROR_UNSUPPORTED_REMOTE_FEATURE	0x1e
 #define HCI_ERROR_INVALID_LL_PARAMS	0x1e
 #define HCI_ERROR_UNSPECIFIED		0x1f
 #define HCI_ERROR_ADVERTISING_TIMEOUT	0x3c
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 13396329f..e8b4a0126 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -92,11 +92,11 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev *hdev, void *data,
 	/* It is possible that we receive Inquiry Complete event right
 	 * before we receive Inquiry Cancel Command Complete event, in
 	 * which case the latter event should have status of Command
-	 * Disallowed (0x0c). This should not be treated as error, since
+	 * Disallowed. This should not be treated as error, since
 	 * we actually achieve what Inquiry Cancel wants to achieve,
 	 * which is to end the last Inquiry session.
 	 */
-	if (rp->status == 0x0c && !test_bit(HCI_INQUIRY, &hdev->flags)) {
+	if (rp->status == HCI_ERROR_COMMAND_DISALLOWED && !test_bit(HCI_INQUIRY, &hdev->flags)) {
 		bt_dev_warn(hdev, "Ignoring error of Inquiry Cancel command");
 		rp->status = 0x00;
 	}
@@ -2323,7 +2323,7 @@ static void hci_cs_create_conn(struct hci_dev *hdev, __u8 status)
 
 	if (status) {
 		if (conn && conn->state == BT_CONNECT) {
-			if (status != 0x0c || conn->attempt > 2) {
+			if (status != HCI_ERROR_COMMAND_DISALLOWED || conn->attempt > 2) {
 				conn->state = BT_CLOSED;
 				hci_connect_cfm(conn, status);
 				hci_conn_del(conn);
@@ -6578,7 +6578,7 @@ static void hci_le_remote_feat_complete_evt(struct hci_dev *hdev, void *data,
 			 * transition into connected state and mark it as
 			 * successful.
 			 */
-			if (!conn->out && ev->status == 0x1a &&
+			if (!conn->out && ev->status == HCI_ERROR_UNSUPPORTED_REMOTE_FEATURE &&
 			    (hdev->le_features[0] & HCI_LE_PERIPHERAL_FEATURES))
 				status = 0x00;
 			else
-- 
2.43.0

[PATCH v2 3/4] Bluetooth: hci_conn: Only do ACL connections sequentially

[Jonas Dreßler]

Pretty much all bluetooth chipsets only support paging a single device at
a time, and if they don't reject a secondary "Create Connection" request
while another is still ongoing, they'll most likely serialize those
requests in the firware.

With commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect
requests") we started adding some serialization of our own in case the
adapter returns "Command Disallowed" HCI error.

This commit was using the BT_CONNECT2 state for the serialization, this
state is also used for a few more things (most notably to indicate we're
waiting for an inquiry to cancel) and therefore a bit unreliable. Also
not all BT firwares would respond with "Command Disallowed" on too many
connection requests, some will also respond with "Hardware Failure"
(BCM4378), and others will error out later and send a "Connect Complete"
event with error "Rejected Limited Resources" (Marvell 88W8897).

We can clean things up a bit and also make the serialization more reliable
by using our hci_sync machinery to always do "Create Connection" requests
in a sequential manner.

This is very similar to what we're already doing for establishing LE
connections, and it works well there.
---
 include/net/bluetooth/hci.h |  1 +
 net/bluetooth/hci_conn.c    | 37 ++++++++++++++++++++++++++-----------
 2 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index fef723afd..f2bbc0a14 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -427,6 +427,7 @@ enum {
 #define HCI_ACL_TX_TIMEOUT	msecs_to_jiffies(45000)	/* 45 seconds */
 #define HCI_AUTO_OFF_TIMEOUT	msecs_to_jiffies(2000)	/* 2 seconds */
 #define HCI_POWER_OFF_TIMEOUT	msecs_to_jiffies(5000)	/* 5 seconds */
+#define HCI_ACL_CONN_TIMEOUT	msecs_to_jiffies(20000)	/* 20 seconds */
 #define HCI_LE_CONN_TIMEOUT	msecs_to_jiffies(20000)	/* 20 seconds */
 #define HCI_LE_AUTOCONN_TIMEOUT	msecs_to_jiffies(4000)	/* 4 seconds */
 
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 76222565e..541d55301 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -229,11 +229,12 @@ static void hci_connect_le_scan_remove(struct hci_conn *conn)
 	schedule_work(&conn->le_scan_cleanup);
 }
 
-static void hci_acl_create_connection(struct hci_conn *conn)
+static int hci_acl_create_connection_sync(struct hci_dev *hdev, void *data)
 {
-	struct hci_dev *hdev = conn->hdev;
+	struct hci_conn *conn = data;
 	struct inquiry_entry *ie;
 	struct hci_cp_create_conn cp;
+	int err;
 
 	BT_DBG("hcon %p", conn);
 
@@ -246,12 +247,10 @@ static void hci_acl_create_connection(struct hci_conn *conn)
 	 * request for discovery again when this flag becomes false.
 	 */
 	if (test_bit(HCI_INQUIRY, &hdev->flags)) {
-		/* Put this connection to "pending" state so that it will be
-		 * executed after the inquiry cancel command complete event.
-		 */
-		conn->state = BT_CONNECT2;
-		hci_send_cmd(hdev, HCI_OP_INQUIRY_CANCEL, 0, NULL);
-		return;
+		err = __hci_cmd_sync_status(hdev, HCI_OP_INQUIRY_CANCEL, 0,
+					    NULL, HCI_CMD_TIMEOUT);
+		if (err)
+			bt_dev_warn(hdev, "Failed to cancel inquiry %d", err);
 	}
 
 	conn->state = BT_CONNECT;
@@ -284,7 +283,15 @@ static void hci_acl_create_connection(struct hci_conn *conn)
 	else
 		cp.role_switch = 0x00;
 
-	hci_send_cmd(hdev, HCI_OP_CREATE_CONN, sizeof(cp), &cp);
+	err = __hci_cmd_sync_status_sk(hdev, HCI_OP_CREATE_CONN,
+				       sizeof(cp), &cp,
+				       HCI_EV_CONN_COMPLETE,
+				       HCI_ACL_CONN_TIMEOUT, NULL);
+
+	if (err == -ETIMEDOUT)
+		hci_abort_conn(conn, HCI_ERROR_LOCAL_HOST_TERM);
+
+	return err;
 }
 
 int hci_disconnect(struct hci_conn *conn, __u8 reason)
@@ -1622,10 +1629,18 @@ struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
 
 	acl->conn_reason = conn_reason;
 	if (acl->state == BT_OPEN || acl->state == BT_CLOSED) {
+		int err;
+
 		acl->sec_level = BT_SECURITY_LOW;
 		acl->pending_sec_level = sec_level;
 		acl->auth_type = auth_type;
-		hci_acl_create_connection(acl);
+
+		err = hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync,
+					 acl, NULL);
+		if (err) {
+			hci_conn_del(acl);
+			return ERR_PTR(err);
+		}
 	}
 
 	return acl;
@@ -2530,7 +2545,7 @@ void hci_conn_check_pending(struct hci_dev *hdev)
 
 	conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
 	if (conn)
-		hci_acl_create_connection(conn);
+		hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync, conn, NULL);
 
 	hci_dev_unlock(hdev);
 }
-- 
2.43.0

Re: [PATCH v2 3/4] Bluetooth: hci_conn: Only do ACL connections sequentially

[Luiz Augusto von Dentz]

Hi Jonas,

On Mon, Jan 8, 2024 at 1:39 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>
> Pretty much all bluetooth chipsets only support paging a single device at
> a time, and if they don't reject a secondary "Create Connection" request
> while another is still ongoing, they'll most likely serialize those
> requests in the firware.
>
> With commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect
> requests") we started adding some serialization of our own in case the
> adapter returns "Command Disallowed" HCI error.
>
> This commit was using the BT_CONNECT2 state for the serialization, this
> state is also used for a few more things (most notably to indicate we're
> waiting for an inquiry to cancel) and therefore a bit unreliable. Also
> not all BT firwares would respond with "Command Disallowed" on too many
> connection requests, some will also respond with "Hardware Failure"
> (BCM4378), and others will error out later and send a "Connect Complete"
> event with error "Rejected Limited Resources" (Marvell 88W8897).
>
> We can clean things up a bit and also make the serialization more reliable
> by using our hci_sync machinery to always do "Create Connection" requests
> in a sequential manner.
>
> This is very similar to what we're already doing for establishing LE
> connections, and it works well there.
> ---
>  include/net/bluetooth/hci.h |  1 +
>  net/bluetooth/hci_conn.c    | 37 ++++++++++++++++++++++++++-----------
>  2 files changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index fef723afd..f2bbc0a14 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -427,6 +427,7 @@ enum {
>  #define HCI_ACL_TX_TIMEOUT     msecs_to_jiffies(45000) /* 45 seconds */
>  #define HCI_AUTO_OFF_TIMEOUT   msecs_to_jiffies(2000)  /* 2 seconds */
>  #define HCI_POWER_OFF_TIMEOUT  msecs_to_jiffies(5000)  /* 5 seconds */
> +#define HCI_ACL_CONN_TIMEOUT   msecs_to_jiffies(20000) /* 20 seconds */
>  #define HCI_LE_CONN_TIMEOUT    msecs_to_jiffies(20000) /* 20 seconds */
>  #define HCI_LE_AUTOCONN_TIMEOUT        msecs_to_jiffies(4000)  /* 4 seconds */
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 76222565e..541d55301 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -229,11 +229,12 @@ static void hci_connect_le_scan_remove(struct hci_conn *conn)
>         schedule_work(&conn->le_scan_cleanup);
>  }
>
> -static void hci_acl_create_connection(struct hci_conn *conn)
> +static int hci_acl_create_connection_sync(struct hci_dev *hdev, void *data)

Move the above function to hci_sync.c so it is simpler to reuse it in
the future.

>  {
> -       struct hci_dev *hdev = conn->hdev;
> +       struct hci_conn *conn = data;
>         struct inquiry_entry *ie;
>         struct hci_cp_create_conn cp;
> +       int err;
>
>         BT_DBG("hcon %p", conn);
>
> @@ -246,12 +247,10 @@ static void hci_acl_create_connection(struct hci_conn *conn)
>          * request for discovery again when this flag becomes false.
>          */
>         if (test_bit(HCI_INQUIRY, &hdev->flags)) {
> -               /* Put this connection to "pending" state so that it will be
> -                * executed after the inquiry cancel command complete event.
> -                */
> -               conn->state = BT_CONNECT2;
> -               hci_send_cmd(hdev, HCI_OP_INQUIRY_CANCEL, 0, NULL);
> -               return;
> +               err = __hci_cmd_sync_status(hdev, HCI_OP_INQUIRY_CANCEL, 0,
> +                                           NULL, HCI_CMD_TIMEOUT);
> +               if (err)
> +                       bt_dev_warn(hdev, "Failed to cancel inquiry %d", err);
>         }
>
>         conn->state = BT_CONNECT;
> @@ -284,7 +283,15 @@ static void hci_acl_create_connection(struct hci_conn *conn)
>         else
>                 cp.role_switch = 0x00;
>
> -       hci_send_cmd(hdev, HCI_OP_CREATE_CONN, sizeof(cp), &cp);
> +       err = __hci_cmd_sync_status_sk(hdev, HCI_OP_CREATE_CONN,
> +                                      sizeof(cp), &cp,
> +                                      HCI_EV_CONN_COMPLETE,
> +                                      HCI_ACL_CONN_TIMEOUT, NULL);
> +
> +       if (err == -ETIMEDOUT)
> +               hci_abort_conn(conn, HCI_ERROR_LOCAL_HOST_TERM);
> +
> +       return err;
>  }
>
>  int hci_disconnect(struct hci_conn *conn, __u8 reason)
> @@ -1622,10 +1629,18 @@ struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
>
>         acl->conn_reason = conn_reason;
>         if (acl->state == BT_OPEN || acl->state == BT_CLOSED) {
> +               int err;
> +
>                 acl->sec_level = BT_SECURITY_LOW;
>                 acl->pending_sec_level = sec_level;
>                 acl->auth_type = auth_type;
> -               hci_acl_create_connection(acl);
> +
> +               err = hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync,
> +                                        acl, NULL);
> +               if (err) {
> +                       hci_conn_del(acl);
> +                       return ERR_PTR(err);
> +               }
>         }
>
>         return acl;
> @@ -2530,7 +2545,7 @@ void hci_conn_check_pending(struct hci_dev *hdev)
>
>         conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
>         if (conn)
> -               hci_acl_create_connection(conn);
> +               hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync, conn, NULL);
>
>         hci_dev_unlock(hdev);
>  }
> --
> 2.43.0
>


-- 
Luiz Augusto von Dentz

[PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Jonas Dreßler]

With the last commit we moved to using the hci_sync queue for "Create
Connection" requests, removing the need for retrying the paging after
finished/failed "Create Connection" requests and after the end of
inquiries.

hci_conn_check_pending() was used to trigger this retry, we can remove it
now.

Note that we can also remove the special handling for COMMAND_DISALLOWED
errors in the completion handler of "Create Connection", because "Create
Connection" requests are now always serialized.

This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
concurrent connect requests").

With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
back to meaning only one thing: That we received a connection request
from another device (see hci_conn_request_evt), but the actual connect
should be deferred.
---
 include/net/bluetooth/hci_core.h |  1 -
 net/bluetooth/hci_conn.c         | 16 ----------------
 net/bluetooth/hci_event.c        | 21 ++++-----------------
 3 files changed, 4 insertions(+), 34 deletions(-)

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 2c30834c1..d7483958d 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
 			      u8 role);
 void hci_conn_del(struct hci_conn *conn);
 void hci_conn_hash_flush(struct hci_dev *hdev);
-void hci_conn_check_pending(struct hci_dev *hdev);
 
 struct hci_chan *hci_chan_create(struct hci_conn *conn);
 void hci_chan_del(struct hci_chan *chan);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 541d55301..22033057b 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
 	}
 }
 
-/* Check pending connect attempts */
-void hci_conn_check_pending(struct hci_dev *hdev)
-{
-	struct hci_conn *conn;
-
-	BT_DBG("hdev %s", hdev->name);
-
-	hci_dev_lock(hdev);
-
-	conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
-	if (conn)
-		hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync, conn, NULL);
-
-	hci_dev_unlock(hdev);
-}
-
 static u32 get_link_mode(struct hci_conn *conn)
 {
 	u32 link_mode = 0;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index e8b4a0126..91973d6d1 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev *hdev, void *data,
 		hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
 	hci_dev_unlock(hdev);
 
-	hci_conn_check_pending(hdev);
-
 	return rp->status;
 }
 
@@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev *hdev, void *data,
 
 	hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
 
-	hci_conn_check_pending(hdev);
-
 	return rp->status;
 }
 
@@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev *hdev, __u8 status)
 {
 	bt_dev_dbg(hdev, "status 0x%2.2x", status);
 
-	if (status) {
-		hci_conn_check_pending(hdev);
+	if (status)
 		return;
-	}
 
 	set_bit(HCI_INQUIRY, &hdev->flags);
 }
@@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev *hdev, __u8 status)
 
 	if (status) {
 		if (conn && conn->state == BT_CONNECT) {
-			if (status != HCI_ERROR_COMMAND_DISALLOWED || conn->attempt > 2) {
-				conn->state = BT_CLOSED;
-				hci_connect_cfm(conn, status);
-				hci_conn_del(conn);
-			} else
-				conn->state = BT_CONNECT2;
+			conn->state = BT_CLOSED;
+			hci_connect_cfm(conn, status);
+			hci_conn_del(conn);
 		}
 	} else {
 		if (!conn) {
@@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct hci_dev *hdev, void *data,
 
 	bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
 
-	hci_conn_check_pending(hdev);
-
 	if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
 		return;
 
@@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, void *data,
 
 unlock:
 	hci_dev_unlock(hdev);
-
-	hci_conn_check_pending(hdev);
 }
 
 static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)
-- 
2.43.0

Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Jonas Dreßler]

On 1/8/24 19:39, Jonas Dreßler wrote:
> With the last commit we moved to using the hci_sync queue for "Create
> Connection" requests, removing the need for retrying the paging after
> finished/failed "Create Connection" requests and after the end of
> inquiries.
> 
> hci_conn_check_pending() was used to trigger this retry, we can remove it
> now.
> 
> Note that we can also remove the special handling for COMMAND_DISALLOWED
> errors in the completion handler of "Create Connection", because "Create
> Connection" requests are now always serialized.
> 
> This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
> concurrent connect requests").
> 
> With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
> back to meaning only one thing: That we received a connection request
> from another device (see hci_conn_request_evt), but the actual connect
> should be deferred.
> ---
>   include/net/bluetooth/hci_core.h |  1 -
>   net/bluetooth/hci_conn.c         | 16 ----------------
>   net/bluetooth/hci_event.c        | 21 ++++-----------------
>   3 files changed, 4 insertions(+), 34 deletions(-)
> 
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 2c30834c1..d7483958d 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst,
>   			      u8 role);
>   void hci_conn_del(struct hci_conn *conn);
>   void hci_conn_hash_flush(struct hci_dev *hdev);
> -void hci_conn_check_pending(struct hci_dev *hdev);
>   
>   struct hci_chan *hci_chan_create(struct hci_conn *conn);
>   void hci_chan_del(struct hci_chan *chan);
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 541d55301..22033057b 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
>   	}
>   }
>   
> -/* Check pending connect attempts */
> -void hci_conn_check_pending(struct hci_dev *hdev)
> -{
> -	struct hci_conn *conn;
> -
> -	BT_DBG("hdev %s", hdev->name);
> -
> -	hci_dev_lock(hdev);
> -
> -	conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
> -	if (conn)
> -		hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync, conn, NULL);
> -
> -	hci_dev_unlock(hdev);
> -}
> -
>   static u32 get_link_mode(struct hci_conn *conn)
>   {
>   	u32 link_mode = 0;
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index e8b4a0126..91973d6d1 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev *hdev, void *data,
>   		hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
>   	hci_dev_unlock(hdev);
>   
> -	hci_conn_check_pending(hdev);
> -
>   	return rp->status;
>   }
>   
> @@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev *hdev, void *data,
>   
>   	hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
>   
> -	hci_conn_check_pending(hdev);
> -
>   	return rp->status;
>   }
>   
> @@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev *hdev, __u8 status)
>   {
>   	bt_dev_dbg(hdev, "status 0x%2.2x", status);
>   
> -	if (status) {
> -		hci_conn_check_pending(hdev);
> +	if (status)
>   		return;
> -	}
>   
>   	set_bit(HCI_INQUIRY, &hdev->flags);
>   }
> @@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev *hdev, __u8 status)
>   
>   	if (status) {
>   		if (conn && conn->state == BT_CONNECT) {
> -			if (status != HCI_ERROR_COMMAND_DISALLOWED || conn->attempt > 2) {
> -				conn->state = BT_CLOSED;
> -				hci_connect_cfm(conn, status);
> -				hci_conn_del(conn);
> -			} else
> -				conn->state = BT_CONNECT2;
> +			conn->state = BT_CLOSED;
> +			hci_connect_cfm(conn, status);
> +			hci_conn_del(conn);
>   		}
>   	} else {
>   		if (!conn) {
> @@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct hci_dev *hdev, void *data,
>   
>   	bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
>   
> -	hci_conn_check_pending(hdev);
> -
>   	if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
>   		return;
>   
> @@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, void *data,
>   
>   unlock:
>   	hci_dev_unlock(hdev);
> -
> -	hci_conn_check_pending(hdev);
>   }
>   
>   static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)

Please take a special look at this one: I'm not sure if I'm breaking the 
functionality of deferred connecting using BT_CONNECT2 in 
hci_conn_request_evt() here, as I don't see anywhere where we check for 
this state and establish a connection later.

It seems that this is how hci_conn_request_evt() was initially written 
though, hci_conn_check_pending() only got introduced later and seems 
unrelated.

Thanks,
Jonas

Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Jonas Dreßler]

On 1/8/24 19:44, Jonas Dreßler wrote:
> On 1/8/24 19:39, Jonas Dreßler wrote:
>> With the last commit we moved to using the hci_sync queue for "Create
>> Connection" requests, removing the need for retrying the paging after
>> finished/failed "Create Connection" requests and after the end of
>> inquiries.
>>
>> hci_conn_check_pending() was used to trigger this retry, we can remove it
>> now.
>>
>> Note that we can also remove the special handling for COMMAND_DISALLOWED
>> errors in the completion handler of "Create Connection", because "Create
>> Connection" requests are now always serialized.
>>
>> This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
>> concurrent connect requests").
>>
>> With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
>> back to meaning only one thing: That we received a connection request
>> from another device (see hci_conn_request_evt), but the actual connect
>> should be deferred.
>> ---
>>   include/net/bluetooth/hci_core.h |  1 -
>>   net/bluetooth/hci_conn.c         | 16 ----------------
>>   net/bluetooth/hci_event.c        | 21 ++++-----------------
>>   3 files changed, 4 insertions(+), 34 deletions(-)
>>
>> diff --git a/include/net/bluetooth/hci_core.h 
>> b/include/net/bluetooth/hci_core.h
>> index 2c30834c1..d7483958d 100644
>> --- a/include/net/bluetooth/hci_core.h
>> +++ b/include/net/bluetooth/hci_core.h
>> @@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev 
>> *hdev, int type, bdaddr_t *dst,
>>                     u8 role);
>>   void hci_conn_del(struct hci_conn *conn);
>>   void hci_conn_hash_flush(struct hci_dev *hdev);
>> -void hci_conn_check_pending(struct hci_dev *hdev);
>>   struct hci_chan *hci_chan_create(struct hci_conn *conn);
>>   void hci_chan_del(struct hci_chan *chan);
>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> index 541d55301..22033057b 100644
>> --- a/net/bluetooth/hci_conn.c
>> +++ b/net/bluetooth/hci_conn.c
>> @@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
>>       }
>>   }
>> -/* Check pending connect attempts */
>> -void hci_conn_check_pending(struct hci_dev *hdev)
>> -{
>> -    struct hci_conn *conn;
>> -
>> -    BT_DBG("hdev %s", hdev->name);
>> -
>> -    hci_dev_lock(hdev);
>> -
>> -    conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
>> -    if (conn)
>> -        hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync, 
>> conn, NULL);
>> -
>> -    hci_dev_unlock(hdev);
>> -}
>> -
>>   static u32 get_link_mode(struct hci_conn *conn)
>>   {
>>       u32 link_mode = 0;
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index e8b4a0126..91973d6d1 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev 
>> *hdev, void *data,
>>           hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
>>       hci_dev_unlock(hdev);
>> -    hci_conn_check_pending(hdev);
>> -
>>       return rp->status;
>>   }
>> @@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev 
>> *hdev, void *data,
>>       hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
>> -    hci_conn_check_pending(hdev);
>> -
>>       return rp->status;
>>   }
>> @@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev 
>> *hdev, __u8 status)
>>   {
>>       bt_dev_dbg(hdev, "status 0x%2.2x", status);
>> -    if (status) {
>> -        hci_conn_check_pending(hdev);
>> +    if (status)
>>           return;
>> -    }
>>       set_bit(HCI_INQUIRY, &hdev->flags);
>>   }
>> @@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev 
>> *hdev, __u8 status)
>>       if (status) {
>>           if (conn && conn->state == BT_CONNECT) {
>> -            if (status != HCI_ERROR_COMMAND_DISALLOWED || 
>> conn->attempt > 2) {
>> -                conn->state = BT_CLOSED;
>> -                hci_connect_cfm(conn, status);
>> -                hci_conn_del(conn);
>> -            } else
>> -                conn->state = BT_CONNECT2;
>> +            conn->state = BT_CLOSED;
>> +            hci_connect_cfm(conn, status);
>> +            hci_conn_del(conn);
>>           }
>>       } else {
>>           if (!conn) {
>> @@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct 
>> hci_dev *hdev, void *data,
>>       bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
>> -    hci_conn_check_pending(hdev);
>> -
>>       if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
>>           return;
>> @@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev 
>> *hdev, void *data,
>>   unlock:
>>       hci_dev_unlock(hdev);
>> -
>> -    hci_conn_check_pending(hdev);
>>   }
>>   static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)
> 
> Please take a special look at this one: I'm not sure if I'm breaking the 
> functionality of deferred connecting using BT_CONNECT2 in 
> hci_conn_request_evt() here, as I don't see anywhere where we check for 
> this state and establish a connection later.
> 
> It seems that this is how hci_conn_request_evt() was initially written 
> though, hci_conn_check_pending() only got introduced later and seems 
> unrelated.

Ahh nevermind... The check for BT_CONNECT2 on "Conn Complete event" got 
introduced with 4c67bc74f01 ([Bluetooth] Support concurrent connect 
requests). And later the deferred connection setup on "Conn Request 
event" got introduced with 20714bfef8 ("Bluetooth: Implement deferred 
sco socket setup").

I assume the latter commit was relying on the "Create Connection" 
request "Conn Complete event" that got introduced with the former commit 
then? That would imply that we use BT_CONNECT2 if there's already a 
"Create Connection" going on when the "Conn Request event" happens, and 
we must wait for that existing request to finish.. Is that how those 
deferred connections are supposed to work?

> 
> Thanks,
> Jonas

Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Luiz Augusto von Dentz]

Hi Jonas,

On Mon, Jan 8, 2024 at 1:55 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>
> On 1/8/24 19:44, Jonas Dreßler wrote:
> > On 1/8/24 19:39, Jonas Dreßler wrote:
> >> With the last commit we moved to using the hci_sync queue for "Create
> >> Connection" requests, removing the need for retrying the paging after
> >> finished/failed "Create Connection" requests and after the end of
> >> inquiries.
> >>
> >> hci_conn_check_pending() was used to trigger this retry, we can remove it
> >> now.
> >>
> >> Note that we can also remove the special handling for COMMAND_DISALLOWED
> >> errors in the completion handler of "Create Connection", because "Create
> >> Connection" requests are now always serialized.
> >>
> >> This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
> >> concurrent connect requests").
> >>
> >> With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
> >> back to meaning only one thing: That we received a connection request
> >> from another device (see hci_conn_request_evt), but the actual connect
> >> should be deferred.
> >> ---
> >>   include/net/bluetooth/hci_core.h |  1 -
> >>   net/bluetooth/hci_conn.c         | 16 ----------------
> >>   net/bluetooth/hci_event.c        | 21 ++++-----------------
> >>   3 files changed, 4 insertions(+), 34 deletions(-)
> >>
> >> diff --git a/include/net/bluetooth/hci_core.h
> >> b/include/net/bluetooth/hci_core.h
> >> index 2c30834c1..d7483958d 100644
> >> --- a/include/net/bluetooth/hci_core.h
> >> +++ b/include/net/bluetooth/hci_core.h
> >> @@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev
> >> *hdev, int type, bdaddr_t *dst,
> >>                     u8 role);
> >>   void hci_conn_del(struct hci_conn *conn);
> >>   void hci_conn_hash_flush(struct hci_dev *hdev);
> >> -void hci_conn_check_pending(struct hci_dev *hdev);
> >>   struct hci_chan *hci_chan_create(struct hci_conn *conn);
> >>   void hci_chan_del(struct hci_chan *chan);
> >> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> >> index 541d55301..22033057b 100644
> >> --- a/net/bluetooth/hci_conn.c
> >> +++ b/net/bluetooth/hci_conn.c
> >> @@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
> >>       }
> >>   }
> >> -/* Check pending connect attempts */
> >> -void hci_conn_check_pending(struct hci_dev *hdev)
> >> -{
> >> -    struct hci_conn *conn;
> >> -
> >> -    BT_DBG("hdev %s", hdev->name);
> >> -
> >> -    hci_dev_lock(hdev);
> >> -
> >> -    conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
> >> -    if (conn)
> >> -        hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync,
> >> conn, NULL);
> >> -
> >> -    hci_dev_unlock(hdev);
> >> -}
> >> -
> >>   static u32 get_link_mode(struct hci_conn *conn)
> >>   {
> >>       u32 link_mode = 0;
> >> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> >> index e8b4a0126..91973d6d1 100644
> >> --- a/net/bluetooth/hci_event.c
> >> +++ b/net/bluetooth/hci_event.c
> >> @@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev
> >> *hdev, void *data,
> >>           hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
> >>       hci_dev_unlock(hdev);
> >> -    hci_conn_check_pending(hdev);
> >> -
> >>       return rp->status;
> >>   }
> >> @@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev
> >> *hdev, void *data,
> >>       hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
> >> -    hci_conn_check_pending(hdev);
> >> -
> >>       return rp->status;
> >>   }
> >> @@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev
> >> *hdev, __u8 status)
> >>   {
> >>       bt_dev_dbg(hdev, "status 0x%2.2x", status);
> >> -    if (status) {
> >> -        hci_conn_check_pending(hdev);
> >> +    if (status)
> >>           return;
> >> -    }
> >>       set_bit(HCI_INQUIRY, &hdev->flags);
> >>   }
> >> @@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev
> >> *hdev, __u8 status)
> >>       if (status) {
> >>           if (conn && conn->state == BT_CONNECT) {
> >> -            if (status != HCI_ERROR_COMMAND_DISALLOWED ||
> >> conn->attempt > 2) {
> >> -                conn->state = BT_CLOSED;
> >> -                hci_connect_cfm(conn, status);
> >> -                hci_conn_del(conn);
> >> -            } else
> >> -                conn->state = BT_CONNECT2;
> >> +            conn->state = BT_CLOSED;
> >> +            hci_connect_cfm(conn, status);
> >> +            hci_conn_del(conn);
> >>           }
> >>       } else {
> >>           if (!conn) {
> >> @@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct
> >> hci_dev *hdev, void *data,
> >>       bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
> >> -    hci_conn_check_pending(hdev);
> >> -
> >>       if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
> >>           return;
> >> @@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev
> >> *hdev, void *data,
> >>   unlock:
> >>       hci_dev_unlock(hdev);
> >> -
> >> -    hci_conn_check_pending(hdev);
> >>   }
> >>   static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)
> >
> > Please take a special look at this one: I'm not sure if I'm breaking the
> > functionality of deferred connecting using BT_CONNECT2 in
> > hci_conn_request_evt() here, as I don't see anywhere where we check for
> > this state and establish a connection later.
> >
> > It seems that this is how hci_conn_request_evt() was initially written
> > though, hci_conn_check_pending() only got introduced later and seems
> > unrelated.
>
> Ahh nevermind... The check for BT_CONNECT2 on "Conn Complete event" got
> introduced with 4c67bc74f01 ([Bluetooth] Support concurrent connect
> requests). And later the deferred connection setup on "Conn Request
> event" got introduced with 20714bfef8 ("Bluetooth: Implement deferred
> sco socket setup").
>
> I assume the latter commit was relying on the "Create Connection"
> request "Conn Complete event" that got introduced with the former commit
> then? That would imply that we use BT_CONNECT2 if there's already a
> "Create Connection" going on when the "Conn Request event" happens, and
> we must wait for that existing request to finish.. Is that how those
> deferred connections are supposed to work?

Well if you are not sure that works we better make sure we have tests
that cover this, for LE I know for sure it works because we have the
likes of iso-tester that do connect 2 peers simultaneously, but for
classic I don't recall having any test that does multiple connections.

> >
> > Thanks,
> > Jonas



-- 
Luiz Augusto von Dentz

Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Jonas Dreßler]

Hi Luiz,

On 1/8/24 20:14, Luiz Augusto von Dentz wrote:
> Hi Jonas,
> 
> On Mon, Jan 8, 2024 at 1:55 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>>
>> On 1/8/24 19:44, Jonas Dreßler wrote:
>>> On 1/8/24 19:39, Jonas Dreßler wrote:
>>>> With the last commit we moved to using the hci_sync queue for "Create
>>>> Connection" requests, removing the need for retrying the paging after
>>>> finished/failed "Create Connection" requests and after the end of
>>>> inquiries.
>>>>
>>>> hci_conn_check_pending() was used to trigger this retry, we can remove it
>>>> now.
>>>>
>>>> Note that we can also remove the special handling for COMMAND_DISALLOWED
>>>> errors in the completion handler of "Create Connection", because "Create
>>>> Connection" requests are now always serialized.
>>>>
>>>> This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
>>>> concurrent connect requests").
>>>>
>>>> With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
>>>> back to meaning only one thing: That we received a connection request
>>>> from another device (see hci_conn_request_evt), but the actual connect
>>>> should be deferred.
>>>> ---
>>>>    include/net/bluetooth/hci_core.h |  1 -
>>>>    net/bluetooth/hci_conn.c         | 16 ----------------
>>>>    net/bluetooth/hci_event.c        | 21 ++++-----------------
>>>>    3 files changed, 4 insertions(+), 34 deletions(-)
>>>>
>>>> diff --git a/include/net/bluetooth/hci_core.h
>>>> b/include/net/bluetooth/hci_core.h
>>>> index 2c30834c1..d7483958d 100644
>>>> --- a/include/net/bluetooth/hci_core.h
>>>> +++ b/include/net/bluetooth/hci_core.h
>>>> @@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev
>>>> *hdev, int type, bdaddr_t *dst,
>>>>                      u8 role);
>>>>    void hci_conn_del(struct hci_conn *conn);
>>>>    void hci_conn_hash_flush(struct hci_dev *hdev);
>>>> -void hci_conn_check_pending(struct hci_dev *hdev);
>>>>    struct hci_chan *hci_chan_create(struct hci_conn *conn);
>>>>    void hci_chan_del(struct hci_chan *chan);
>>>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>>>> index 541d55301..22033057b 100644
>>>> --- a/net/bluetooth/hci_conn.c
>>>> +++ b/net/bluetooth/hci_conn.c
>>>> @@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
>>>>        }
>>>>    }
>>>> -/* Check pending connect attempts */
>>>> -void hci_conn_check_pending(struct hci_dev *hdev)
>>>> -{
>>>> -    struct hci_conn *conn;
>>>> -
>>>> -    BT_DBG("hdev %s", hdev->name);
>>>> -
>>>> -    hci_dev_lock(hdev);
>>>> -
>>>> -    conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
>>>> -    if (conn)
>>>> -        hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync,
>>>> conn, NULL);
>>>> -
>>>> -    hci_dev_unlock(hdev);
>>>> -}
>>>> -
>>>>    static u32 get_link_mode(struct hci_conn *conn)
>>>>    {
>>>>        u32 link_mode = 0;
>>>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>>>> index e8b4a0126..91973d6d1 100644
>>>> --- a/net/bluetooth/hci_event.c
>>>> +++ b/net/bluetooth/hci_event.c
>>>> @@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev
>>>> *hdev, void *data,
>>>>            hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
>>>>        hci_dev_unlock(hdev);
>>>> -    hci_conn_check_pending(hdev);
>>>> -
>>>>        return rp->status;
>>>>    }
>>>> @@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev
>>>> *hdev, void *data,
>>>>        hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
>>>> -    hci_conn_check_pending(hdev);
>>>> -
>>>>        return rp->status;
>>>>    }
>>>> @@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev
>>>> *hdev, __u8 status)
>>>>    {
>>>>        bt_dev_dbg(hdev, "status 0x%2.2x", status);
>>>> -    if (status) {
>>>> -        hci_conn_check_pending(hdev);
>>>> +    if (status)
>>>>            return;
>>>> -    }
>>>>        set_bit(HCI_INQUIRY, &hdev->flags);
>>>>    }
>>>> @@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev
>>>> *hdev, __u8 status)
>>>>        if (status) {
>>>>            if (conn && conn->state == BT_CONNECT) {
>>>> -            if (status != HCI_ERROR_COMMAND_DISALLOWED ||
>>>> conn->attempt > 2) {
>>>> -                conn->state = BT_CLOSED;
>>>> -                hci_connect_cfm(conn, status);
>>>> -                hci_conn_del(conn);
>>>> -            } else
>>>> -                conn->state = BT_CONNECT2;
>>>> +            conn->state = BT_CLOSED;
>>>> +            hci_connect_cfm(conn, status);
>>>> +            hci_conn_del(conn);
>>>>            }
>>>>        } else {
>>>>            if (!conn) {
>>>> @@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct
>>>> hci_dev *hdev, void *data,
>>>>        bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
>>>> -    hci_conn_check_pending(hdev);
>>>> -
>>>>        if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
>>>>            return;
>>>> @@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev
>>>> *hdev, void *data,
>>>>    unlock:
>>>>        hci_dev_unlock(hdev);
>>>> -
>>>> -    hci_conn_check_pending(hdev);
>>>>    }
>>>>    static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)
>>>
>>> Please take a special look at this one: I'm not sure if I'm breaking the
>>> functionality of deferred connecting using BT_CONNECT2 in
>>> hci_conn_request_evt() here, as I don't see anywhere where we check for
>>> this state and establish a connection later.
>>>
>>> It seems that this is how hci_conn_request_evt() was initially written
>>> though, hci_conn_check_pending() only got introduced later and seems
>>> unrelated.
>>
>> Ahh nevermind... The check for BT_CONNECT2 on "Conn Complete event" got
>> introduced with 4c67bc74f01 ([Bluetooth] Support concurrent connect
>> requests). And later the deferred connection setup on "Conn Request
>> event" got introduced with 20714bfef8 ("Bluetooth: Implement deferred
>> sco socket setup").
>>
>> I assume the latter commit was relying on the "Create Connection"
>> request "Conn Complete event" that got introduced with the former commit
>> then? That would imply that we use BT_CONNECT2 if there's already a
>> "Create Connection" going on when the "Conn Request event" happens, and
>> we must wait for that existing request to finish.. Is that how those
>> deferred connections are supposed to work?
> 
> Well if you are not sure that works we better make sure we have tests
> that cover this, for LE I know for sure it works because we have the
> likes of iso-tester that do connect 2 peers simultaneously, but for
> classic I don't recall having any test that does multiple connections.

The sequential "Create Connection" logic works, I tested that (of course 
I'm happy to add tests if it's not too much work).

What I'm unsure about is if and how incoming connection requests from 
other devices with HCI_PROTO_DEFER flag are supposed to work and whether 
they are meant to trigger a "Create Connection" from us?

> 
>>>
>>> Thanks,
>>> Jonas
> 
> 
> 

Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Luiz Augusto von Dentz]

Hi Jonas,

On Mon, Jan 8, 2024 at 2:29 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>
> Hi Luiz,
>
> On 1/8/24 20:14, Luiz Augusto von Dentz wrote:
> > Hi Jonas,
> >
> > On Mon, Jan 8, 2024 at 1:55 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
> >>
> >> On 1/8/24 19:44, Jonas Dreßler wrote:
> >>> On 1/8/24 19:39, Jonas Dreßler wrote:
> >>>> With the last commit we moved to using the hci_sync queue for "Create
> >>>> Connection" requests, removing the need for retrying the paging after
> >>>> finished/failed "Create Connection" requests and after the end of
> >>>> inquiries.
> >>>>
> >>>> hci_conn_check_pending() was used to trigger this retry, we can remove it
> >>>> now.
> >>>>
> >>>> Note that we can also remove the special handling for COMMAND_DISALLOWED
> >>>> errors in the completion handler of "Create Connection", because "Create
> >>>> Connection" requests are now always serialized.
> >>>>
> >>>> This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
> >>>> concurrent connect requests").
> >>>>
> >>>> With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
> >>>> back to meaning only one thing: That we received a connection request
> >>>> from another device (see hci_conn_request_evt), but the actual connect
> >>>> should be deferred.
> >>>> ---
> >>>>    include/net/bluetooth/hci_core.h |  1 -
> >>>>    net/bluetooth/hci_conn.c         | 16 ----------------
> >>>>    net/bluetooth/hci_event.c        | 21 ++++-----------------
> >>>>    3 files changed, 4 insertions(+), 34 deletions(-)
> >>>>
> >>>> diff --git a/include/net/bluetooth/hci_core.h
> >>>> b/include/net/bluetooth/hci_core.h
> >>>> index 2c30834c1..d7483958d 100644
> >>>> --- a/include/net/bluetooth/hci_core.h
> >>>> +++ b/include/net/bluetooth/hci_core.h
> >>>> @@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev
> >>>> *hdev, int type, bdaddr_t *dst,
> >>>>                      u8 role);
> >>>>    void hci_conn_del(struct hci_conn *conn);
> >>>>    void hci_conn_hash_flush(struct hci_dev *hdev);
> >>>> -void hci_conn_check_pending(struct hci_dev *hdev);
> >>>>    struct hci_chan *hci_chan_create(struct hci_conn *conn);
> >>>>    void hci_chan_del(struct hci_chan *chan);
> >>>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> >>>> index 541d55301..22033057b 100644
> >>>> --- a/net/bluetooth/hci_conn.c
> >>>> +++ b/net/bluetooth/hci_conn.c
> >>>> @@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
> >>>>        }
> >>>>    }
> >>>> -/* Check pending connect attempts */
> >>>> -void hci_conn_check_pending(struct hci_dev *hdev)
> >>>> -{
> >>>> -    struct hci_conn *conn;
> >>>> -
> >>>> -    BT_DBG("hdev %s", hdev->name);
> >>>> -
> >>>> -    hci_dev_lock(hdev);
> >>>> -
> >>>> -    conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
> >>>> -    if (conn)
> >>>> -        hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync,
> >>>> conn, NULL);
> >>>> -
> >>>> -    hci_dev_unlock(hdev);
> >>>> -}
> >>>> -
> >>>>    static u32 get_link_mode(struct hci_conn *conn)
> >>>>    {
> >>>>        u32 link_mode = 0;
> >>>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> >>>> index e8b4a0126..91973d6d1 100644
> >>>> --- a/net/bluetooth/hci_event.c
> >>>> +++ b/net/bluetooth/hci_event.c
> >>>> @@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev
> >>>> *hdev, void *data,
> >>>>            hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
> >>>>        hci_dev_unlock(hdev);
> >>>> -    hci_conn_check_pending(hdev);
> >>>> -
> >>>>        return rp->status;
> >>>>    }
> >>>> @@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev
> >>>> *hdev, void *data,
> >>>>        hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
> >>>> -    hci_conn_check_pending(hdev);
> >>>> -
> >>>>        return rp->status;
> >>>>    }
> >>>> @@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev
> >>>> *hdev, __u8 status)
> >>>>    {
> >>>>        bt_dev_dbg(hdev, "status 0x%2.2x", status);
> >>>> -    if (status) {
> >>>> -        hci_conn_check_pending(hdev);
> >>>> +    if (status)
> >>>>            return;
> >>>> -    }
> >>>>        set_bit(HCI_INQUIRY, &hdev->flags);
> >>>>    }
> >>>> @@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev
> >>>> *hdev, __u8 status)
> >>>>        if (status) {
> >>>>            if (conn && conn->state == BT_CONNECT) {
> >>>> -            if (status != HCI_ERROR_COMMAND_DISALLOWED ||
> >>>> conn->attempt > 2) {
> >>>> -                conn->state = BT_CLOSED;
> >>>> -                hci_connect_cfm(conn, status);
> >>>> -                hci_conn_del(conn);
> >>>> -            } else
> >>>> -                conn->state = BT_CONNECT2;
> >>>> +            conn->state = BT_CLOSED;
> >>>> +            hci_connect_cfm(conn, status);
> >>>> +            hci_conn_del(conn);
> >>>>            }
> >>>>        } else {
> >>>>            if (!conn) {
> >>>> @@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct
> >>>> hci_dev *hdev, void *data,
> >>>>        bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
> >>>> -    hci_conn_check_pending(hdev);
> >>>> -
> >>>>        if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
> >>>>            return;
> >>>> @@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev
> >>>> *hdev, void *data,
> >>>>    unlock:
> >>>>        hci_dev_unlock(hdev);
> >>>> -
> >>>> -    hci_conn_check_pending(hdev);
> >>>>    }
> >>>>    static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)
> >>>
> >>> Please take a special look at this one: I'm not sure if I'm breaking the
> >>> functionality of deferred connecting using BT_CONNECT2 in
> >>> hci_conn_request_evt() here, as I don't see anywhere where we check for
> >>> this state and establish a connection later.
> >>>
> >>> It seems that this is how hci_conn_request_evt() was initially written
> >>> though, hci_conn_check_pending() only got introduced later and seems
> >>> unrelated.
> >>
> >> Ahh nevermind... The check for BT_CONNECT2 on "Conn Complete event" got
> >> introduced with 4c67bc74f01 ([Bluetooth] Support concurrent connect
> >> requests). And later the deferred connection setup on "Conn Request
> >> event" got introduced with 20714bfef8 ("Bluetooth: Implement deferred
> >> sco socket setup").
> >>
> >> I assume the latter commit was relying on the "Create Connection"
> >> request "Conn Complete event" that got introduced with the former commit
> >> then? That would imply that we use BT_CONNECT2 if there's already a
> >> "Create Connection" going on when the "Conn Request event" happens, and
> >> we must wait for that existing request to finish.. Is that how those
> >> deferred connections are supposed to work?
> >
> > Well if you are not sure that works we better make sure we have tests
> > that cover this, for LE I know for sure it works because we have the
> > likes of iso-tester that do connect 2 peers simultaneously, but for
> > classic I don't recall having any test that does multiple connections.
>
> The sequential "Create Connection" logic works, I tested that (of course
> I'm happy to add tests if it's not too much work).
>
> What I'm unsure about is if and how incoming connection requests from
> other devices with HCI_PROTO_DEFER flag are supposed to work and whether
> they are meant to trigger a "Create Connection" from us?

For incoming connections on Classic that should result in an
accept/reject connection command, so it should cause another Create
Connection if that is what you are afraid of.

> >
> >>>
> >>> Thanks,
> >>> Jonas
> >
> >
> >



-- 
Luiz Augusto von Dentz

Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Jonas Dreßler]

Hi Luiz,

On 1/8/24 20:41, Luiz Augusto von Dentz wrote:
> Hi Jonas,
> 
> On Mon, Jan 8, 2024 at 2:29 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>>
>> Hi Luiz,
>>
>> On 1/8/24 20:14, Luiz Augusto von Dentz wrote:
>>> Hi Jonas,
>>>
>>> On Mon, Jan 8, 2024 at 1:55 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>>>>
>>>> On 1/8/24 19:44, Jonas Dreßler wrote:
>>>>> On 1/8/24 19:39, Jonas Dreßler wrote:
>>>>>> With the last commit we moved to using the hci_sync queue for "Create
>>>>>> Connection" requests, removing the need for retrying the paging after
>>>>>> finished/failed "Create Connection" requests and after the end of
>>>>>> inquiries.
>>>>>>
>>>>>> hci_conn_check_pending() was used to trigger this retry, we can remove it
>>>>>> now.
>>>>>>
>>>>>> Note that we can also remove the special handling for COMMAND_DISALLOWED
>>>>>> errors in the completion handler of "Create Connection", because "Create
>>>>>> Connection" requests are now always serialized.
>>>>>>
>>>>>> This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
>>>>>> concurrent connect requests").
>>>>>>
>>>>>> With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
>>>>>> back to meaning only one thing: That we received a connection request
>>>>>> from another device (see hci_conn_request_evt), but the actual connect
>>>>>> should be deferred.
>>>>>> ---
>>>>>>     include/net/bluetooth/hci_core.h |  1 -
>>>>>>     net/bluetooth/hci_conn.c         | 16 ----------------
>>>>>>     net/bluetooth/hci_event.c        | 21 ++++-----------------
>>>>>>     3 files changed, 4 insertions(+), 34 deletions(-)
>>>>>>
>>>>>> diff --git a/include/net/bluetooth/hci_core.h
>>>>>> b/include/net/bluetooth/hci_core.h
>>>>>> index 2c30834c1..d7483958d 100644
>>>>>> --- a/include/net/bluetooth/hci_core.h
>>>>>> +++ b/include/net/bluetooth/hci_core.h
>>>>>> @@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev
>>>>>> *hdev, int type, bdaddr_t *dst,
>>>>>>                       u8 role);
>>>>>>     void hci_conn_del(struct hci_conn *conn);
>>>>>>     void hci_conn_hash_flush(struct hci_dev *hdev);
>>>>>> -void hci_conn_check_pending(struct hci_dev *hdev);
>>>>>>     struct hci_chan *hci_chan_create(struct hci_conn *conn);
>>>>>>     void hci_chan_del(struct hci_chan *chan);
>>>>>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>>>>>> index 541d55301..22033057b 100644
>>>>>> --- a/net/bluetooth/hci_conn.c
>>>>>> +++ b/net/bluetooth/hci_conn.c
>>>>>> @@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
>>>>>>         }
>>>>>>     }
>>>>>> -/* Check pending connect attempts */
>>>>>> -void hci_conn_check_pending(struct hci_dev *hdev)
>>>>>> -{
>>>>>> -    struct hci_conn *conn;
>>>>>> -
>>>>>> -    BT_DBG("hdev %s", hdev->name);
>>>>>> -
>>>>>> -    hci_dev_lock(hdev);
>>>>>> -
>>>>>> -    conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
>>>>>> -    if (conn)
>>>>>> -        hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync,
>>>>>> conn, NULL);
>>>>>> -
>>>>>> -    hci_dev_unlock(hdev);
>>>>>> -}
>>>>>> -
>>>>>>     static u32 get_link_mode(struct hci_conn *conn)
>>>>>>     {
>>>>>>         u32 link_mode = 0;
>>>>>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>>>>>> index e8b4a0126..91973d6d1 100644
>>>>>> --- a/net/bluetooth/hci_event.c
>>>>>> +++ b/net/bluetooth/hci_event.c
>>>>>> @@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev
>>>>>> *hdev, void *data,
>>>>>>             hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
>>>>>>         hci_dev_unlock(hdev);
>>>>>> -    hci_conn_check_pending(hdev);
>>>>>> -
>>>>>>         return rp->status;
>>>>>>     }
>>>>>> @@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev
>>>>>> *hdev, void *data,
>>>>>>         hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
>>>>>> -    hci_conn_check_pending(hdev);
>>>>>> -
>>>>>>         return rp->status;
>>>>>>     }
>>>>>> @@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev
>>>>>> *hdev, __u8 status)
>>>>>>     {
>>>>>>         bt_dev_dbg(hdev, "status 0x%2.2x", status);
>>>>>> -    if (status) {
>>>>>> -        hci_conn_check_pending(hdev);
>>>>>> +    if (status)
>>>>>>             return;
>>>>>> -    }
>>>>>>         set_bit(HCI_INQUIRY, &hdev->flags);
>>>>>>     }
>>>>>> @@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev
>>>>>> *hdev, __u8 status)
>>>>>>         if (status) {
>>>>>>             if (conn && conn->state == BT_CONNECT) {
>>>>>> -            if (status != HCI_ERROR_COMMAND_DISALLOWED ||
>>>>>> conn->attempt > 2) {
>>>>>> -                conn->state = BT_CLOSED;
>>>>>> -                hci_connect_cfm(conn, status);
>>>>>> -                hci_conn_del(conn);
>>>>>> -            } else
>>>>>> -                conn->state = BT_CONNECT2;
>>>>>> +            conn->state = BT_CLOSED;
>>>>>> +            hci_connect_cfm(conn, status);
>>>>>> +            hci_conn_del(conn);
>>>>>>             }
>>>>>>         } else {
>>>>>>             if (!conn) {
>>>>>> @@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct
>>>>>> hci_dev *hdev, void *data,
>>>>>>         bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
>>>>>> -    hci_conn_check_pending(hdev);
>>>>>> -
>>>>>>         if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
>>>>>>             return;
>>>>>> @@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev
>>>>>> *hdev, void *data,
>>>>>>     unlock:
>>>>>>         hci_dev_unlock(hdev);
>>>>>> -
>>>>>> -    hci_conn_check_pending(hdev);
>>>>>>     }
>>>>>>     static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)
>>>>>
>>>>> Please take a special look at this one: I'm not sure if I'm breaking the
>>>>> functionality of deferred connecting using BT_CONNECT2 in
>>>>> hci_conn_request_evt() here, as I don't see anywhere where we check for
>>>>> this state and establish a connection later.
>>>>>
>>>>> It seems that this is how hci_conn_request_evt() was initially written
>>>>> though, hci_conn_check_pending() only got introduced later and seems
>>>>> unrelated.
>>>>
>>>> Ahh nevermind... The check for BT_CONNECT2 on "Conn Complete event" got
>>>> introduced with 4c67bc74f01 ([Bluetooth] Support concurrent connect
>>>> requests). And later the deferred connection setup on "Conn Request
>>>> event" got introduced with 20714bfef8 ("Bluetooth: Implement deferred
>>>> sco socket setup").
>>>>
>>>> I assume the latter commit was relying on the "Create Connection"
>>>> request "Conn Complete event" that got introduced with the former commit
>>>> then? That would imply that we use BT_CONNECT2 if there's already a
>>>> "Create Connection" going on when the "Conn Request event" happens, and
>>>> we must wait for that existing request to finish.. Is that how those
>>>> deferred connections are supposed to work?
>>>
>>> Well if you are not sure that works we better make sure we have tests
>>> that cover this, for LE I know for sure it works because we have the
>>> likes of iso-tester that do connect 2 peers simultaneously, but for
>>> classic I don't recall having any test that does multiple connections.
>>
>> The sequential "Create Connection" logic works, I tested that (of course
>> I'm happy to add tests if it's not too much work).
>>
>> What I'm unsure about is if and how incoming connection requests from
>> other devices with HCI_PROTO_DEFER flag are supposed to work and whether
>> they are meant to trigger a "Create Connection" from us?
> 
> For incoming connections on Classic that should result in an
> accept/reject connection command, so it should cause another Create
> Connection if that is what you are afraid of.
> 

Hmm, do you mean it *shouldn't* cause another "Create Connection"?

I just checked in the spec: It sounds like once we send the "Accept 
Connection Request" to the controller, the controller takes care of 
establishing the connection by itself (no "Create Connection" 
necessary), and will then later give us a "Connection Complete" event to 
indicate that the connection is done.

If I'm reading all this correctly, that sounds like my commit is 
correct, and we had a bug in this logic before by interpreting 
BT_CONNECT2 in two different ways.

>>>
>>>>>
>>>>> Thanks,
>>>>> Jonas
>>>
>>>
>>>
> 
> 
> 

Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts

[Luiz Augusto von Dentz]

Hi Jonas,

On Mon, Jan 8, 2024 at 3:26 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
>
> Hi Luiz,
>
> On 1/8/24 20:41, Luiz Augusto von Dentz wrote:
> > Hi Jonas,
> >
> > On Mon, Jan 8, 2024 at 2:29 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
> >>
> >> Hi Luiz,
> >>
> >> On 1/8/24 20:14, Luiz Augusto von Dentz wrote:
> >>> Hi Jonas,
> >>>
> >>> On Mon, Jan 8, 2024 at 1:55 PM Jonas Dreßler <verdre@v0yd.nl> wrote:
> >>>>
> >>>> On 1/8/24 19:44, Jonas Dreßler wrote:
> >>>>> On 1/8/24 19:39, Jonas Dreßler wrote:
> >>>>>> With the last commit we moved to using the hci_sync queue for "Create
> >>>>>> Connection" requests, removing the need for retrying the paging after
> >>>>>> finished/failed "Create Connection" requests and after the end of
> >>>>>> inquiries.
> >>>>>>
> >>>>>> hci_conn_check_pending() was used to trigger this retry, we can remove it
> >>>>>> now.
> >>>>>>
> >>>>>> Note that we can also remove the special handling for COMMAND_DISALLOWED
> >>>>>> errors in the completion handler of "Create Connection", because "Create
> >>>>>> Connection" requests are now always serialized.
> >>>>>>
> >>>>>> This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support
> >>>>>> concurrent connect requests").
> >>>>>>
> >>>>>> With this, the BT_CONNECT2 state of ACL hci_conn objects should now be
> >>>>>> back to meaning only one thing: That we received a connection request
> >>>>>> from another device (see hci_conn_request_evt), but the actual connect
> >>>>>> should be deferred.
> >>>>>> ---
> >>>>>>     include/net/bluetooth/hci_core.h |  1 -
> >>>>>>     net/bluetooth/hci_conn.c         | 16 ----------------
> >>>>>>     net/bluetooth/hci_event.c        | 21 ++++-----------------
> >>>>>>     3 files changed, 4 insertions(+), 34 deletions(-)
> >>>>>>
> >>>>>> diff --git a/include/net/bluetooth/hci_core.h
> >>>>>> b/include/net/bluetooth/hci_core.h
> >>>>>> index 2c30834c1..d7483958d 100644
> >>>>>> --- a/include/net/bluetooth/hci_core.h
> >>>>>> +++ b/include/net/bluetooth/hci_core.h
> >>>>>> @@ -1330,7 +1330,6 @@ struct hci_conn *hci_conn_add(struct hci_dev
> >>>>>> *hdev, int type, bdaddr_t *dst,
> >>>>>>                       u8 role);
> >>>>>>     void hci_conn_del(struct hci_conn *conn);
> >>>>>>     void hci_conn_hash_flush(struct hci_dev *hdev);
> >>>>>> -void hci_conn_check_pending(struct hci_dev *hdev);
> >>>>>>     struct hci_chan *hci_chan_create(struct hci_conn *conn);
> >>>>>>     void hci_chan_del(struct hci_chan *chan);
> >>>>>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> >>>>>> index 541d55301..22033057b 100644
> >>>>>> --- a/net/bluetooth/hci_conn.c
> >>>>>> +++ b/net/bluetooth/hci_conn.c
> >>>>>> @@ -2534,22 +2534,6 @@ void hci_conn_hash_flush(struct hci_dev *hdev)
> >>>>>>         }
> >>>>>>     }
> >>>>>> -/* Check pending connect attempts */
> >>>>>> -void hci_conn_check_pending(struct hci_dev *hdev)
> >>>>>> -{
> >>>>>> -    struct hci_conn *conn;
> >>>>>> -
> >>>>>> -    BT_DBG("hdev %s", hdev->name);
> >>>>>> -
> >>>>>> -    hci_dev_lock(hdev);
> >>>>>> -
> >>>>>> -    conn = hci_conn_hash_lookup_state(hdev, ACL_LINK, BT_CONNECT2);
> >>>>>> -    if (conn)
> >>>>>> -        hci_cmd_sync_queue(hdev, hci_acl_create_connection_sync,
> >>>>>> conn, NULL);
> >>>>>> -
> >>>>>> -    hci_dev_unlock(hdev);
> >>>>>> -}
> >>>>>> -
> >>>>>>     static u32 get_link_mode(struct hci_conn *conn)
> >>>>>>     {
> >>>>>>         u32 link_mode = 0;
> >>>>>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> >>>>>> index e8b4a0126..91973d6d1 100644
> >>>>>> --- a/net/bluetooth/hci_event.c
> >>>>>> +++ b/net/bluetooth/hci_event.c
> >>>>>> @@ -117,8 +117,6 @@ static u8 hci_cc_inquiry_cancel(struct hci_dev
> >>>>>> *hdev, void *data,
> >>>>>>             hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
> >>>>>>         hci_dev_unlock(hdev);
> >>>>>> -    hci_conn_check_pending(hdev);
> >>>>>> -
> >>>>>>         return rp->status;
> >>>>>>     }
> >>>>>> @@ -149,8 +147,6 @@ static u8 hci_cc_exit_periodic_inq(struct hci_dev
> >>>>>> *hdev, void *data,
> >>>>>>         hci_dev_clear_flag(hdev, HCI_PERIODIC_INQ);
> >>>>>> -    hci_conn_check_pending(hdev);
> >>>>>> -
> >>>>>>         return rp->status;
> >>>>>>     }
> >>>>>> @@ -2296,10 +2292,8 @@ static void hci_cs_inquiry(struct hci_dev
> >>>>>> *hdev, __u8 status)
> >>>>>>     {
> >>>>>>         bt_dev_dbg(hdev, "status 0x%2.2x", status);
> >>>>>> -    if (status) {
> >>>>>> -        hci_conn_check_pending(hdev);
> >>>>>> +    if (status)
> >>>>>>             return;
> >>>>>> -    }
> >>>>>>         set_bit(HCI_INQUIRY, &hdev->flags);
> >>>>>>     }
> >>>>>> @@ -2323,12 +2317,9 @@ static void hci_cs_create_conn(struct hci_dev
> >>>>>> *hdev, __u8 status)
> >>>>>>         if (status) {
> >>>>>>             if (conn && conn->state == BT_CONNECT) {
> >>>>>> -            if (status != HCI_ERROR_COMMAND_DISALLOWED ||
> >>>>>> conn->attempt > 2) {
> >>>>>> -                conn->state = BT_CLOSED;
> >>>>>> -                hci_connect_cfm(conn, status);
> >>>>>> -                hci_conn_del(conn);
> >>>>>> -            } else
> >>>>>> -                conn->state = BT_CONNECT2;
> >>>>>> +            conn->state = BT_CLOSED;
> >>>>>> +            hci_connect_cfm(conn, status);
> >>>>>> +            hci_conn_del(conn);
> >>>>>>             }
> >>>>>>         } else {
> >>>>>>             if (!conn) {
> >>>>>> @@ -3020,8 +3011,6 @@ static void hci_inquiry_complete_evt(struct
> >>>>>> hci_dev *hdev, void *data,
> >>>>>>         bt_dev_dbg(hdev, "status 0x%2.2x", ev->status);
> >>>>>> -    hci_conn_check_pending(hdev);
> >>>>>> -
> >>>>>>         if (!test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
> >>>>>>             return;
> >>>>>> @@ -3247,8 +3236,6 @@ static void hci_conn_complete_evt(struct hci_dev
> >>>>>> *hdev, void *data,
> >>>>>>     unlock:
> >>>>>>         hci_dev_unlock(hdev);
> >>>>>> -
> >>>>>> -    hci_conn_check_pending(hdev);
> >>>>>>     }
> >>>>>>     static void hci_reject_conn(struct hci_dev *hdev, bdaddr_t *bdaddr)
> >>>>>
> >>>>> Please take a special look at this one: I'm not sure if I'm breaking the
> >>>>> functionality of deferred connecting using BT_CONNECT2 in
> >>>>> hci_conn_request_evt() here, as I don't see anywhere where we check for
> >>>>> this state and establish a connection later.
> >>>>>
> >>>>> It seems that this is how hci_conn_request_evt() was initially written
> >>>>> though, hci_conn_check_pending() only got introduced later and seems
> >>>>> unrelated.
> >>>>
> >>>> Ahh nevermind... The check for BT_CONNECT2 on "Conn Complete event" got
> >>>> introduced with 4c67bc74f01 ([Bluetooth] Support concurrent connect
> >>>> requests). And later the deferred connection setup on "Conn Request
> >>>> event" got introduced with 20714bfef8 ("Bluetooth: Implement deferred
> >>>> sco socket setup").
> >>>>
> >>>> I assume the latter commit was relying on the "Create Connection"
> >>>> request "Conn Complete event" that got introduced with the former commit
> >>>> then? That would imply that we use BT_CONNECT2 if there's already a
> >>>> "Create Connection" going on when the "Conn Request event" happens, and
> >>>> we must wait for that existing request to finish.. Is that how those
> >>>> deferred connections are supposed to work?
> >>>
> >>> Well if you are not sure that works we better make sure we have tests
> >>> that cover this, for LE I know for sure it works because we have the
> >>> likes of iso-tester that do connect 2 peers simultaneously, but for
> >>> classic I don't recall having any test that does multiple connections.
> >>
> >> The sequential "Create Connection" logic works, I tested that (of course
> >> I'm happy to add tests if it's not too much work).
> >>
> >> What I'm unsure about is if and how incoming connection requests from
> >> other devices with HCI_PROTO_DEFER flag are supposed to work and whether
> >> they are meant to trigger a "Create Connection" from us?
> >
> > For incoming connections on Classic that should result in an
> > accept/reject connection command, so it should cause another Create
> > Connection if that is what you are afraid of.
> >
>
> Hmm, do you mean it *shouldn't* cause another "Create Connection"?

Yeah, sorry about that, it is Monday I should probably double check if
what I wrote makes any sense before sending :D

> I just checked in the spec: It sounds like once we send the "Accept
> Connection Request" to the controller, the controller takes care of
> establishing the connection by itself (no "Create Connection"
> necessary), and will then later give us a "Connection Complete" event to
> indicate that the connection is done.

Yep, it will follow up with a Connection Complete.

> If I'm reading all this correctly, that sounds like my commit is
> correct, and we had a bug in this logic before by interpreting
> BT_CONNECT2 in two different ways.
>
> >>>
> >>>>>
> >>>>> Thanks,
> >>>>> Jonas
> >>>
> >>>
> >>>
> >
> >
> >



-- 
Luiz Augusto von Dentz