Re: [PATCH v5] thunderbolt: Fix tb->lock deadlock during hot-unplug on AMD USB4 routers

[Mika Westerberg]

Hi,

On Tue, Sep 15, 2026 at 04:51:00AM +0000, S, Sanath wrote:
> Ported it and stressed it on two Strix Halo hosts connected back to back.
> REG_CAPS reports hop_count = 3 here, so two usable DMA HopIDs. Observations:
> 
>  - Single tunnel it works: 50 x traffic then link down/up, plus 42 x
>    dma_test create / transfer / teardown. One reset per cycle, no ping loss,
>    no errors, and every ring restart had a reset before it.
> 
>  - Every reset is preceded by "dangling request in request_queue" and a
>    WARNING from tb_ctl_stop(), 8 of 8 cycles, via tb_domain_pause() <-
>    tb_ring_start() <- tbnet_connected_work().
> 
>  - Two tunnels: the networking ring is stopped and restarted with no reset
>    in between, because the check only runs in nhi_alloc_hop() and tbnet
>    reuses its rings across a reconnect. 18 such cycles did not hang, so the
>    unsafe reuse is reachable but I cannot say it hangs.
> 
>  - When the check does fire it takes networking down, reproduced twice:
>    "RTNETLINK answers: Cannot allocate memory" plus "out of HopIDs that do
>    not need a host interface reset", until the second tunnel stops.
> 
>  - tb_domain_pause() takes tb->lock from tb_ring_start(), while unplug holds
>    tb->lock across tbnet_remove() -> stop_login() ->
>    cancel_work_sync(&net->connected_work).
> 
> Moving the reset into a per-NHI work item scheduled from tb_ring_stop() when
> the last DMA ring stops removes the warning and the tb->lock inversion, and
> passes the same tests cleanly. The reuse hole and the lockout still need the
> reset to key off ring reuse rather than ring allocation.
> 
> Mika, Can I respin your patch along those lines and post it as a new version?

Of course. I'm thinking though that should we do the revert for v7.3-rcX
now and then do the proper fix for v7.4 with your updated patch?