[PATCH 1/5] wifi: mt76: fix potential deadlock caused by rx_lock

[Felix Fietkau]

On 02.02.26 08:53, Shayne Chen wrote:
> A deadlock will occur if both of the following conditions are met,
> because they each attempt to acquire the rx_lock:
> - mac80211 receives an unexpected BAR control frame, which triggers
>    a BA deletion
> - A transmission failure happens due to an abnormality in DMA
> 
> Since ieee80211_tx_status_ext() is primarily used to address AQL issues,
> avoid potential deadlocks by restricting calls to ieee80211_tx_status_ext
> only for data frames.

First of all, ieee80211_tx_status_ext is not primarily used to address 
AQL, ieee80211_free_txskb handles it as well. The reason for it is tx 
status handling, e.g. for management frames sent by hostapd that require 
an ACK status report, so limiting the status calls for data frames seems 
wrong to me.

I don't really understand how the scenario you're describing leads to a 
deadlock. From my understanding, if something in the mac80211 rx path 
triggers a tx, it should end up calling mt76_tx(), which queues the skb 
to wcid->tx_list and triggers the tx worker. So the actual dma tx callls 
are expected to come from the worker kthread.
How does this lead to a deadlock on rx_lock?

- Felix