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

[Mario Limonciello]

On 9/15/26 01:04, Mika Westerberg wrote:
> 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?

Yeah; I think that's the right call right now given the timing and risk.