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

[Mario Limonciello <superm1@kernel.org>]

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.