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

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ó
[off-list ref] wrote:

quoted

quoted

quoted

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

quoted

quoted

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.

quoted

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.