[PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Luiz Augusto von Dentz]

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

This attempts to proper track outstanding request by using struct ida
and allocating from it in l2cap_get_ident using ida_alloc_range which
would reuse ids as they are free, then upon completion release
the id using ida_free.

This fixes the qualification test case L2CAP/COS/CED/BI-29-C which
attempts to check if the host stack is able to work after 256 attempts
to connect which would for Ident field to use the full range.

Link: https://github.com/bluez/bluez/issues/1829
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
 include/net/bluetooth/l2cap.h |  3 +--
 net/bluetooth/l2cap_core.c    | 46 ++++++++++++++++++++++++-----------
 2 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 00e182a22720..ec3af01e4db9 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -655,8 +655,7 @@ struct l2cap_conn {
 
 	struct sk_buff		*rx_skb;
 	__u32			rx_len;
-	__u8			tx_ident;
-	struct mutex		ident_lock;
+	struct ida		tx_ida;
 
 	struct sk_buff_head	pending_rx;
 	struct work_struct	pending_rx_work;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 07b493331fd7..b628b0fa39b2 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -924,26 +924,18 @@ int l2cap_chan_check_security(struct l2cap_chan *chan, bool initiator)
 				 initiator);
 }
 
-static u8 l2cap_get_ident(struct l2cap_conn *conn)
+static int l2cap_get_ident(struct l2cap_conn *conn)
 {
-	u8 id;
+	/* LE link does not support tools like l2ping so use the full range */
+	if (conn->hcon->type == LE_LINK)
+		return ida_alloc_range(&conn->tx_ida, 1, 255, GFP_ATOMIC);
 
 	/* Get next available identificator.
 	 *    1 - 128 are used by kernel.
 	 *  129 - 199 are reserved.
 	 *  200 - 254 are used by utilities like l2ping, etc.
 	 */
-
-	mutex_lock(&conn->ident_lock);
-
-	if (++conn->tx_ident > 128)
-		conn->tx_ident = 1;
-
-	id = conn->tx_ident;
-
-	mutex_unlock(&conn->ident_lock);
-
-	return id;
+	return ida_alloc_range(&conn->tx_ida, 1, 128, GFP_ATOMIC);
 }
 
 static void l2cap_send_acl(struct l2cap_conn *conn, struct sk_buff *skb,
@@ -1773,6 +1765,8 @@ static void l2cap_conn_del(struct hci_conn *hcon, int err)
 	if (work_pending(&conn->pending_rx_work))
 		cancel_work_sync(&conn->pending_rx_work);
 
+	ida_destroy(&conn->tx_ida);
+
 	cancel_delayed_work_sync(&conn->id_addr_timer);
 
 	l2cap_unregister_all_users(conn);
@@ -4782,12 +4776,34 @@ static int l2cap_le_connect_rsp(struct l2cap_conn *conn,
 	return err;
 }
 
+static void l2cap_put_ident(struct l2cap_conn *conn, u8 code, u8 id)
+{
+	switch (code) {
+	case L2CAP_COMMAND_REJ:
+	case L2CAP_CONN_RSP:
+	case L2CAP_CONF_RSP:
+	case L2CAP_DISCONN_RSP:
+	case L2CAP_ECHO_RSP:
+	case L2CAP_INFO_RSP:
+	case L2CAP_CONN_PARAM_UPDATE_RSP:
+	case L2CAP_ECRED_CONN_RSP:
+	case L2CAP_ECRED_RECONF_RSP:
+		/* First do a lookup since the remote may send bogus ids that
+		 * would make ida_free to generate warnings.
+		 */
+		if (ida_find_first_range(&conn->tx_ida, id, id) >= 0)
+			ida_free(&conn->tx_ida, id);
+	}
+}
+
 static inline int l2cap_bredr_sig_cmd(struct l2cap_conn *conn,
 				      struct l2cap_cmd_hdr *cmd, u16 cmd_len,
 				      u8 *data)
 {
 	int err = 0;
 
+	l2cap_put_ident(conn, cmd->code, cmd->ident);
+
 	switch (cmd->code) {
 	case L2CAP_COMMAND_REJ:
 		l2cap_command_rej(conn, cmd, cmd_len, data);
@@ -5419,6 +5435,8 @@ static inline int l2cap_le_sig_cmd(struct l2cap_conn *conn,
 {
 	int err = 0;
 
+	l2cap_put_ident(conn, cmd->code, cmd->ident);
+
 	switch (cmd->code) {
 	case L2CAP_COMMAND_REJ:
 		l2cap_le_command_rej(conn, cmd, cmd_len, data);
@@ -6907,13 +6925,13 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon)
 	     hci_dev_test_flag(hcon->hdev, HCI_FORCE_BREDR_SMP)))
 		conn->local_fixed_chan |= L2CAP_FC_SMP_BREDR;
 
-	mutex_init(&conn->ident_lock);
 	mutex_init(&conn->lock);
 
 	INIT_LIST_HEAD(&conn->chan_l);
 	INIT_LIST_HEAD(&conn->users);
 
 	INIT_DELAYED_WORK(&conn->info_timer, l2cap_info_timeout);
+	ida_init(&conn->tx_ida);
 
 	skb_queue_head_init(&conn->pending_rx);
 	INIT_WORK(&conn->pending_rx_work, process_pending_rx);
-- 
2.52.0

RE: [v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1047242

---Test result---

Test Summary:
CheckPatch                    PENDING   0.48 seconds
GitLint                       PENDING   0.37 seconds
SubjectPrefix                 PASS      0.07 seconds
BuildKernel                   PASS      24.97 seconds
CheckAllWarning               PASS      27.39 seconds
CheckSparse                   PASS      30.86 seconds
BuildKernel32                 PASS      24.67 seconds
TestRunnerSetup               PASS      556.94 seconds
TestRunner_l2cap-tester       PASS      28.76 seconds
TestRunner_iso-tester         PASS      76.65 seconds
TestRunner_bnep-tester        PASS      6.66 seconds
TestRunner_mgmt-tester        FAIL      116.23 seconds
TestRunner_rfcomm-tester      PASS      9.40 seconds
TestRunner_sco-tester         FAIL      14.44 seconds
TestRunner_ioctl-tester       PASS      10.15 seconds
TestRunner_mesh-tester        FAIL      11.47 seconds
TestRunner_smp-tester         PASS      8.57 seconds
TestRunner_userchan-tester    PASS      6.58 seconds
IncrementalBuild              PENDING   0.61 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 486 (98.4%), Failed: 4, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.111 seconds
LL Privacy - Set Flags 1 (Add to RL)                 Failed       0.154 seconds
LL Privacy - Start Discovery 1 (Disable RL)          Failed       0.174 seconds
LL Privacy - Start Discovery 2 (Disable RL)          Failed       0.186 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
BUG: sleeping function called from invalid context at net/core/sock.c:3782
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    1.913 seconds
Mesh - Send cancel - 2                               Timed out    1.996 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Mon, 26 Jan 2026 12:53:40 -0500 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> 
> This attempts to proper track outstanding request by using struct ida
> and allocating from it in l2cap_get_ident using ida_alloc_range which
> would reuse ids as they are free, then upon completion release
> the id using ida_free.
> 
> [...]

Here is the summary with links:
  - [v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident
    https://git.kernel.org/bluetooth/bluetooth-next/c/8e7c7cb168a5

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Paul Menzel]

Dear Luiz,


Thank you for your patch.

Am 26.01.26 um 18:53 schrieb Luiz Augusto von Dentz:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> 
> This attempts to proper track outstanding request by using struct ida

proper*ly*

> and allocating from it in l2cap_get_ident using ida_alloc_range which
> would reuse ids as they are free, then upon completion release
> the id using ida_free.
> 
> This fixes the qualification test case L2CAP/COS/CED/BI-29-C which
> attempts to check if the host stack is able to work after 256 attempts
> to connect which would for Ident field to use the full range.

The last sentence seems incomplete.

> Link: https://github.com/bluez/bluez/issues/1829
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> ---
>   include/net/bluetooth/l2cap.h |  3 +--
>   net/bluetooth/l2cap_core.c    | 46 ++++++++++++++++++++++++-----------
>   2 files changed, 33 insertions(+), 16 deletions(-)
> 
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 00e182a22720..ec3af01e4db9 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -655,8 +655,7 @@ struct l2cap_conn {
>   
>   	struct sk_buff		*rx_skb;
>   	__u32			rx_len;
> -	__u8			tx_ident;
> -	struct mutex		ident_lock;
> +	struct ida		tx_ida;
>   
>   	struct sk_buff_head	pending_rx;
>   	struct work_struct	pending_rx_work;
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 07b493331fd7..b628b0fa39b2 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -924,26 +924,18 @@ int l2cap_chan_check_security(struct l2cap_chan *chan, bool initiator)
>   				 initiator);
>   }
>   
> -static u8 l2cap_get_ident(struct l2cap_conn *conn)
> +static int l2cap_get_ident(struct l2cap_conn *conn)
>   {
> -	u8 id;
> +	/* LE link does not support tools like l2ping so use the full range */
> +	if (conn->hcon->type == LE_LINK)
> +		return ida_alloc_range(&conn->tx_ida, 1, 255, GFP_ATOMIC);
>   
>   	/* Get next available identificator.
>   	 *    1 - 128 are used by kernel.
>   	 *  129 - 199 are reserved.
>   	 *  200 - 254 are used by utilities like l2ping, etc.
>   	 */
> -
> -	mutex_lock(&conn->ident_lock);
> -
> -	if (++conn->tx_ident > 128)
> -		conn->tx_ident = 1;
> -
> -	id = conn->tx_ident;
> -
> -	mutex_unlock(&conn->ident_lock);
> -
> -	return id;
> +	return ida_alloc_range(&conn->tx_ida, 1, 128, GFP_ATOMIC);
>   }
>   
>   static void l2cap_send_acl(struct l2cap_conn *conn, struct sk_buff *skb,
> @@ -1773,6 +1765,8 @@ static void l2cap_conn_del(struct hci_conn *hcon, int err)
>   	if (work_pending(&conn->pending_rx_work))
>   		cancel_work_sync(&conn->pending_rx_work);
>   
> +	ida_destroy(&conn->tx_ida);
> +
>   	cancel_delayed_work_sync(&conn->id_addr_timer);
>   
>   	l2cap_unregister_all_users(conn);
> @@ -4782,12 +4776,34 @@ static int l2cap_le_connect_rsp(struct l2cap_conn *conn,
>   	return err;
>   }
>   
> +static void l2cap_put_ident(struct l2cap_conn *conn, u8 code, u8 id)
> +{
> +	switch (code) {
> +	case L2CAP_COMMAND_REJ:
> +	case L2CAP_CONN_RSP:
> +	case L2CAP_CONF_RSP:
> +	case L2CAP_DISCONN_RSP:
> +	case L2CAP_ECHO_RSP:
> +	case L2CAP_INFO_RSP:
> +	case L2CAP_CONN_PARAM_UPDATE_RSP:
> +	case L2CAP_ECRED_CONN_RSP:
> +	case L2CAP_ECRED_RECONF_RSP:
> +		/* First do a lookup since the remote may send bogus ids that
> +		 * would make ida_free to generate warnings.
> +		 */
> +		if (ida_find_first_range(&conn->tx_ida, id, id) >= 0)
> +			ida_free(&conn->tx_ida, id);
> +	}
> +}
> +
>   static inline int l2cap_bredr_sig_cmd(struct l2cap_conn *conn,
>   				      struct l2cap_cmd_hdr *cmd, u16 cmd_len,
>   				      u8 *data)
>   {
>   	int err = 0;
>   
> +	l2cap_put_ident(conn, cmd->code, cmd->ident);
> +
>   	switch (cmd->code) {
>   	case L2CAP_COMMAND_REJ:
>   		l2cap_command_rej(conn, cmd, cmd_len, data);
> @@ -5419,6 +5435,8 @@ static inline int l2cap_le_sig_cmd(struct l2cap_conn *conn,
>   {
>   	int err = 0;
>   
> +	l2cap_put_ident(conn, cmd->code, cmd->ident);
> +
>   	switch (cmd->code) {
>   	case L2CAP_COMMAND_REJ:
>   		l2cap_le_command_rej(conn, cmd, cmd_len, data);
> @@ -6907,13 +6925,13 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon)
>   	     hci_dev_test_flag(hcon->hdev, HCI_FORCE_BREDR_SMP)))
>   		conn->local_fixed_chan |= L2CAP_FC_SMP_BREDR;
>   
> -	mutex_init(&conn->ident_lock);
>   	mutex_init(&conn->lock);
>   
>   	INIT_LIST_HEAD(&conn->chan_l);
>   	INIT_LIST_HEAD(&conn->users);
>   
>   	INIT_DELAYED_WORK(&conn->info_timer, l2cap_info_timeout);
> +	ida_init(&conn->tx_ida);
>   
>   	skb_queue_head_init(&conn->pending_rx);
>   	INIT_WORK(&conn->pending_rx_work, process_pending_rx);

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Joan Bruguera Micó]

I had trouble connecting my Bluetooth headphones on Linux 7.0-rc1,
and a bisect landed me on this commit 6c3ea155e5ee. A revert fixes it.

The symptom is that when connecting the headphones via bluetoothctl,
it either hangs or appears (in pavucontrol) as if it's using the AAC
codec, but there's no output. Sometimes after some time, it disconnects
and then re-connects successfully but using the MSBC/CVSD codecs.

I haven't had time to troubleshoot this further so far, mainly posting
if it can save someone a bisect.

Bluetooth chip: Intel Corp. AX210 Bluetooth (ThinkPad T14 Gen 2)
Device: Bose QuietComfort Ultra (bluetooth:v009Ep4066d0167)
Bluez 5.86-4 (Arch Linux)
Kconfig: That of the linux-mainline AUR package, plus UBSAN

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Linux regression tracking (Thorsten Leemhuis)]

On 3/2/26 00:36, Joan Bruguera Micó wrote:
> I had trouble connecting my Bluetooth headphones on Linux 7.0-rc1,
> and a bisect landed me on this commit 6c3ea155e5ee. A revert fixes it.
> 
> The symptom is that when connecting the headphones via bluetoothctl,
> it either hangs or appears (in pavucontrol) as if it's using the AAC
> codec, but there's no output. Sometimes after some time, it disconnects
> and then re-connects successfully but using the MSBC/CVSD codecs.
> 
> I haven't had time to troubleshoot this further so far, mainly posting
> if it can save someone a bisect.
> 
> Bluetooth chip: Intel Corp. AX210 Bluetooth (ThinkPad T14 Gen 2)
> Device: Bose QuietComfort Ultra (bluetooth:v009Ep4066d0167)
> Bluez 5.86-4 (Arch Linux)
> Kconfig: That of the linux-mainline AUR package, plus UBSAN

FWIW, someone reported problems due to that commit in bugzilla, too:

To quote https://bugzilla.kernel.org/show_bug.cgi?id=221120:
"""
Bug 221120 - Bluetooth headphones stop connecting properly after commit
6c3ea155e5ee3e56606233acde8309afda66d483

Bisected to this commit. Before this headphones can be connected using
A2DP music profile or HSP/HFP for bidirectional (headphone and
microphone mono). After this dependig on the model of the device it has
only one of options available(Marshall Major iv keeps only HSP while
Chinese no-name keep only A2DP ). Reverting just this commit from
Linus's tree restores normal bluetooth audio.
"""

Ciao, Thorsten

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Luiz Augusto von Dentz]

Hi Joan,

On Sun, Mar 1, 2026 at 6:37 PM Joan Bruguera Micó
<joanbrugueram@gmail.com> wrote:
>
> I had trouble connecting my Bluetooth headphones on Linux 7.0-rc1,
> and a bisect landed me on this commit 6c3ea155e5ee. A revert fixes it.
>
> The symptom is that when connecting the headphones via bluetoothctl,
> it either hangs or appears (in pavucontrol) as if it's using the AAC
> codec, but there's no output. Sometimes after some time, it disconnects
> and then re-connects successfully but using the MSBC/CVSD codecs.
>
> I haven't had time to troubleshoot this further so far, mainly posting
> if it can save someone a bisect.
>
> Bluetooth chip: Intel Corp. AX210 Bluetooth (ThinkPad T14 Gen 2)
> Device: Bose QuietComfort Ultra (bluetooth:v009Ep4066d0167)
> Bluez 5.86-4 (Arch Linux)
> Kconfig: That of the linux-mainline AUR package, plus UBSAN

Weird, there shouldn't be any logical difference but perhaps it's
device-specific. Can you collect the btmon traces? Actually it would
be great to have the before and after traces for comparison.

-- 
Luiz Augusto von Dentz

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Joan Bruguera Micó]

Hi Luiz,

> > I had trouble connecting my Bluetooth headphones on Linux 7.0-rc1,
> > and a bisect landed me on this commit 6c3ea155e5ee. A revert fixes it.
> Weird, there shouldn't be any logical difference but perhaps it's
> device-specific. Can you collect the btmon traces? Actually it would
> be great to have the before and after traces for comparison.

I have attached btmon traces (bad/good) to the open Bugzilla bug.
(https://bugzilla.kernel.org/show_bug.cgi?id=221120), hopefully they
are helpful in diagnosing the issue.

I have also done experiments and found that the regression goes away
if the IDs are not re-used, for example by commenting out the `ida_free`
line, or by replacing `ida_alloc_range` (returns smallest available ID)
with `idr_alloc_cyclic` (returns all IDs before wrapping around).

Though I'm not sure if that is just masking a Kernel bug (e.g. IDs
getting released/reused too early), or if that's necessary for my
hardware to not get confused by the same IDs being quickly reused.

Regards,
- Joan

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Luiz Augusto von Dentz]

Hi Joan,

On Sun, Mar 15, 2026 at 3:44 PM Joan Bruguera Micó
<joanbrugueram@gmail.com> wrote:
>
> Hi Luiz,
>
> > > I had trouble connecting my Bluetooth headphones on Linux 7.0-rc1,
> > > and a bisect landed me on this commit 6c3ea155e5ee. A revert fixes it.
> > Weird, there shouldn't be any logical difference but perhaps it's
> > device-specific. Can you collect the btmon traces? Actually it would
> > be great to have the before and after traces for comparison.
>
> I have attached btmon traces (bad/good) to the open Bugzilla bug.
> (https://bugzilla.kernel.org/show_bug.cgi?id=221120), hopefully they
> are helpful in diagnosing the issue.
>
> I have also done experiments and found that the regression goes away
> if the IDs are not re-used, for example by commenting out the `ida_free`
> line, or by replacing `ida_alloc_range` (returns smallest available ID)
> with `idr_alloc_cyclic` (returns all IDs before wrapping around).

Interesting, I didn't consider that the implementation would care
about reusing the identifier as long as it is not outstanding, but if
making it cyclic resolves the issue, that's probably the case.

> Though I'm not sure if that is just masking a Kernel bug (e.g. IDs
> getting released/reused too early), or if that's necessary for my
> hardware to not get confused by the same IDs being quickly reused.

Even if it is a bug in the remote side I guess we don't want to just
break support, we will just need to make sure using idr_alloc_cyclic
doesn't break L2CAP/COS/CED/BI-29-C qualification test.

> Regards,
> - Joan



-- 
Luiz Augusto von Dentz

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Thorsten Leemhuis]

CCing the net maintainers because this is a regression that Linus afaics
would like to have seen fixed by now.

On 3/16/26 14:37, Luiz Augusto von Dentz wrote:
> On Sun, Mar 15, 2026 at 3:44 PM Joan Bruguera Micó
> <joanbrugueram@gmail.com> wrote:
>>>> I had trouble connecting my Bluetooth headphones on Linux 7.0-rc1,
>>>> and a bisect landed me on this commit 6c3ea155e5ee. A revert fixes it.

Side note: there is now a third report where the reporter confirmed that
reverting this patch (6c3ea155e5ee3e ("Bluetooth: L2CAP: Fix not
tracking outstanding TX ident") [v7.0-rc1]) fixes the issue:
https://bugzilla.kernel.org/show_bug.cgi?id=221177

But I'm writing for another reason:

Luiz, does it look like a fix will become available really soon now? If
not, I wonder if we should just revert the culprit at this point (and
reapply a improved change for 7.1), as the regression was first reported
on 2026-02-22 – so we are way beyond the ""rule of thumb should
generally be "[fix regressions] within a week", preferably before the
next rc."" that Linus recently mentioned:
https://www.kernel.org/doc/html/next/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed

Ciao, Thorsten

>>> Weird, there shouldn't be any logical difference but perhaps it's
>>> device-specific. Can you collect the btmon traces? Actually it would
>>> be great to have the before and after traces for comparison.
>>
>> I have attached btmon traces (bad/good) to the open Bugzilla bug.
>> (https://bugzilla.kernel.org/show_bug.cgi?id=221120), hopefully they
>> are helpful in diagnosing the issue.
>>
>> I have also done experiments and found that the regression goes away
>> if the IDs are not re-used, for example by commenting out the `ida_free`
>> line, or by replacing `ida_alloc_range` (returns smallest available ID)
>> with `idr_alloc_cyclic` (returns all IDs before wrapping around).
> 
> Interesting, I didn't consider that the implementation would care
> about reusing the identifier as long as it is not outstanding, but if
> making it cyclic resolves the issue, that's probably the case.
> 
>> Though I'm not sure if that is just masking a Kernel bug (e.g. IDs
>> getting released/reused too early), or if that's necessary for my
>> hardware to not get confused by the same IDs being quickly reused.
> 
> Even if it is a bug in the remote side I guess we don't want to just
> break support, we will just need to make sure using idr_alloc_cyclic
> doesn't break L2CAP/COS/CED/BI-29-C qualification test.

Re: [PATCH v3] Bluetooth: L2CAP: Fix not tracking outstanding TX ident

[Luiz Augusto von Dentz]

Hi Thorsten,

On Tue, Mar 17, 2026 at 10:18 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> CCing the net maintainers because this is a regression that Linus afaics
> would like to have seen fixed by now.
>
> On 3/16/26 14:37, Luiz Augusto von Dentz wrote:
> > On Sun, Mar 15, 2026 at 3:44 PM Joan Bruguera Micó
> > <joanbrugueram@gmail.com> wrote:
> >>>> I had trouble connecting my Bluetooth headphones on Linux 7.0-rc1,
> >>>> and a bisect landed me on this commit 6c3ea155e5ee. A revert fixes it.
>
> Side note: there is now a third report where the reporter confirmed that
> reverting this patch (6c3ea155e5ee3e ("Bluetooth: L2CAP: Fix not
> tracking outstanding TX ident") [v7.0-rc1]) fixes the issue:
> https://bugzilla.kernel.org/show_bug.cgi?id=221177
>
> But I'm writing for another reason:
>
> Luiz, does it look like a fix will become available really soon now? If
> not, I wonder if we should just revert the culprit at this point (and
> reapply a improved change for 7.1), as the regression was first reported
> on 2026-02-22 – so we are way beyond the ""rule of thumb should
> generally be "[fix regressions] within a week", preferably before the
> next rc."" that Linus recently mentioned:
> https://www.kernel.org/doc/html/next/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed

`idr_alloc_cyclic` is not compatible with `struct ida`, and changing
it to use `struct idr` will probably require reintroducing a lock
since the `idr_` functions appear unsafe to run in any context as the
`ida` versions.


-- 
Luiz Augusto von Dentz