[PATCH net 0/2] net: thunderbolt: two fixes for the failed bring-up path
From: Fan Ye via B4 Relay
Date: Sat Aug 08 2026 - 22:28:50 EST
Both of these are reached through the same branch in
tbnet_connected_work(), on an ASMedia ASM4242 host-to-host link, when
the peer drops out while a connection is being brought up. Cycling the
interface down and up 200 times over 80 minutes hits that branch 23
times across the two hosts, with no fault injection.
They fix two separate defects and neither depends on the other for
correctness - each leaves the other's defect in place. Patch 2 does edit
the lines patch 1 adds, so it will not apply on its own and has to come
second.
1 releases the HopID the allocator actually handed out when it is not
the one that was asked for. Today that id is simply left allocated
for the rest of the XDomain connection.
2 marks the connection as no longer established on the failure paths,
so the next tbnet_tear_down() does not run a second teardown over
work that was already undone. That second teardown stops rings that
were never started, which is a WARNING splat and is fatal under
panic_on_warn, and it hands back a HopID this connection never owned.
Measured on two ASM4242 hosts from a cold boot, no module reloads, only
the thunderbolt-net module differing between the runs:
without with
failed to allocate Rx HopID 11 / 12 9 / 13
ring already stopped + WARNING 22 / 24 0 / 0
(host A / host B)
Two further patches from the same investigation touch
drivers/thunderbolt/ and go to the thunderbolt tree separately.
Per-patch notes, including what I am not claiming, are below the cut in
each patch.
---
Fan Ye (2):
net: thunderbolt: Release the Rx HopID that was handed out on mismatch
net: thunderbolt: Mark the connection down when bringing it up fails
drivers/net/thunderbolt/main.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
---
base-commit: 06cf61899d6498b33e4b7c87d99d5bd471ccc375
change-id: 20260809-b4-tbnet-hopid-6ecfe5472ab5
Best regards,
--
Fan Ye <fy15309206903@xxxxxxxxx>