Re: [PATCH v2 1/2] Bluetooth: L2CAP: handle zero txwin_size in ERTM RFC option

[Luiz Augusto von Dentz]

Hi Michael,

On Wed, Apr 22, 2026 at 10:58 AM Michael Bommarito
<michael.bommarito@xxxxxxxxx> wrote:
>
> On Wed, Apr 22, 2026 at 10:44 AM Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
> > This seems to be going sideways:
> >
> > https://sashiko.dev/#/patchset/CABBYNZ%2Bf3pur4cSsanQ1kvv-yORp2E0qmVLt9si_%2BFnnJup4Ng%40mail.gmail.com
> >
> > Patch 2/2 seems totally broken.
>
> Yeah, not a great turn.  I am struggling to figure out where to move
> some of these parts and where to put the guards without touching too
> much.  As Sashiko pointed out, there are some preexisting bugs or spec
> questions that I don't feel like I should be touching unless we expand
> this to more of a cleanup + hardening patch set.
>
> If we break this down, there are now ~5 different issues in
> adjacent/connected spots:
>
> Ones I was trying to hit or introduced:
> 1. Zero txwin_size in inbound CONFIG_REQ (ERTM RFC) - original bug.
> Need to balance normalization with spec.
> 2. Repeated CONFIG_RSP re-running l2cap_ertm_init in BT_CONNECTED -
> original v2 2/2 target.  We need the guard somewhere safe under the
> state model.
> 3. Zero txwin_size from userspace setsockopt - original v2 1/2 hunk in
> l2cap_sock.c.
>
> Pre-existing issues:
> 3. STREAMING -> ERTM mode switch via late CONF_RSP - pre-existing.
> 4. l2cap_sock_setsockopt_old locking - pre-existing.
>
> It feels like the safe solution is probably going to be at least +100
> or 200 by the time it's done and more than just a hardening patch.  I
> can take a spin at it, but I will probably be slower and more
> bug-prone than someone else.  No pride of ownership here.  Just let me
> know if you want to take the fix over or let me try again

100-200 is not too bad though, if there are splits in, let's say, 5
changes that seem doable, especially now that we can sashiko review it
and point out if we are missing something. Another approach would be
to leave the pre-existing issues to be fixed in a separate set.

> Thanks,
> MIke Bommarito



-- 
Luiz Augusto von Dentz