Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp1828558rdb; Mon, 8 Jan 2024 11:29:43 -0800 (PST) X-Google-Smtp-Source: AGHT+IE7yuRQDrKsCFFzzXtwuAiqjrLXS4BTldz6UObe6PTqceGVHpIbxZ1sctfLt28rOEuNn4HC X-Received: by 2002:a81:8453:0:b0:5e7:b0e9:625 with SMTP id u80-20020a818453000000b005e7b0e90625mr2846964ywf.47.1704742183001; Mon, 08 Jan 2024 11:29:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704742182; cv=none; d=google.com; s=arc-20160816; b=Cpa2sTRs/nuOCG7gfNo/qZMRWFYgxhJniHpO3EQkEcxaNpUS4u1p8XBWSNoE+SdJ6c WDotmdtutJsr1ik3IDeUuuYkHkixMCqtd0I7Bs3EDqknMNQHQ8RmFeLqAXdYdkipbLNS 0dXnVb6YVezuy0cFE42TNVRxFzH+bnfJXtXrFm7O1PU+E62P4wlremeGC6HXNXK01nGA e6+uAdwo+ztYb6BzzSHH4m3GfeD9yB6Ntus0qXxe6xxl27cBPbNR88qd5aQBBd7F0qlk nl7vInbqnCMs8i6qVXO59EMRqKjvA3lDENuDSERTLelwLqd0rqh078IkRaSaxUS2CIDm E5Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=bwLCbokUAliPcU6gIdOaD5hWMPhiKEL8jw0Umi0DFKY=; fh=ejTmNziM7PP6VaYrXzJjZ8S6ziNw4IH2+hp/z/RRgDQ=; b=fhlGAV09J+3JeQ8Qi9yCGfk8qItPjJtIS+jRnbGwQhlqU8ognN8+nZoTQdO2/SFSz4 cNaGrN5y414Zri617UjEamrIeXIp4ba78dGYiglXkB2K625qTCV150vpD3HYpJrZYedC bPaZtc0XPhXbNQbQfu8/yV2TJa5IOMxlINbum2k/GNyi4GeeaGLDO/DSvYUWYud//dnC 9l7ALGQF3FA9dGUyX596kBBaM5qkhSMYbGL6xktWdc1XfohaWF8dBuPgDw7Tb55Kj3ex XgjeYEuDunqoCY5TjE7aNL6a/WQNG6TvZG+zRGJxJvdbV9yi6z794TJDKfoeioA+uv45 SKJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth+bounces-971-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-bluetooth+bounces-971-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id u16-20020a0cf1d0000000b0067f6e471793si562184qvl.553.2024.01.08.11.29.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 11:29:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-971-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-bluetooth+bounces-971-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-bluetooth+bounces-971-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 8731F1C21B1E for ; Mon, 8 Jan 2024 19:29:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6183A54FAB; Mon, 8 Jan 2024 19:29:23 +0000 (UTC) X-Original-To: linux-bluetooth@vger.kernel.org Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BA3445C1C; Mon, 8 Jan 2024 19:29:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=v0yd.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=v0yd.nl Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4T83z03ZNxz9sch; Mon, 8 Jan 2024 20:29:16 +0100 (CET) Message-ID: Date: Mon, 8 Jan 2024 20:29:14 +0100 Precedence: bulk X-Mailing-List: linux-bluetooth@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 4/4] Bluetooth: Remove pending ACL connection attempts Content-Language: en-US To: Luiz Augusto von Dentz Cc: Marcel Holtmann , Johan Hedberg , linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, verdre@v0yd.nl References: <20240108183938.468426-1-verdre@v0yd.nl> <20240108183938.468426-5-verdre@v0yd.nl> <5d1f2013-5758-4d6c-8d01-e96a76bb2686@v0yd.nl> <40550fc1-3b5b-438c-891d-2da0f30874f3@v0yd.nl> From: =?UTF-8?Q?Jonas_Dre=C3=9Fler?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 > > >