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

[Shayne Chen <shayne.chen@mediatek.com>]

On Mon, 2026-02-02 at 09:52 +0100, Felix Fietkau wrote:
> 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?

Hi Felix,

Thanks for the explanation.
I've re-checked the codebase used by the customer when the issue was
reported, and I found that the wcid->tx_list structure was not present
in that version. So yes, this problem should not occur in the current
codebase.

Will drop this patch in v2.

Thanks,
Shayne
> 
> - Felix