[PATCH AUTOSEL 6.15 10/15] wifi: mt76: fix queue assignment for deauth packets
Sasha Levin
sashal at kernel.org
Mon Jul 14 16:06:11 PDT 2025
From: Felix Fietkau <nbd at nbd.name>
[ Upstream commit dedf2ec30fe417d181490896adf89cd6b9885b23 ]
When running in AP mode and deauthenticating a client that's in powersave
mode, the disassoc/deauth packet can get stuck in a tx queue along with
other buffered frames. This can fill up hardware queues with frames
that are only released after the WTBL slot is reused for another client.
Fix this by moving deauth packets to the ALTX queue.
Reported-by: Chad Monroe <chad.monroe at adtran.com>
Link: https://patch.msgid.link/20250707154702.1726-2-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I understand the issue and the fix better. Let me analyze this
commit:
**YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **It fixes a real bug affecting users**: The commit addresses a
specific issue where deauthentication packets sent to clients in
powersave mode can get stuck in hardware TX queues. This causes queue
exhaustion and prevents the WTBL (Wireless Table) slot from being
properly reused for new clients. This is a significant functional bug
that impacts AP mode operation.
2. **The fix is small and contained**: The change is minimal - it only
adds a single condition (`||
ieee80211_is_deauth(hdr->frame_control)`) to the existing queue
assignment logic. This is a low-risk change that doesn't introduce
new functionality or architectural changes.
3. **Clear problem and solution**: The commit message clearly describes
the issue (deauth packets getting stuck with other buffered frames)
and the solution (moving deauth packets to the ALTX/PSD queue). The
fix is logical because:
- According to `ieee80211_is_bufferable_mmpdu()` (line 4517), deauth
frames ARE considered bufferable MMPDUs
- However, when a client is being deauthenticated, we don't want
these frames to be buffered with regular data - they need immediate
transmission
- The PSD (Power Save Delivery) queue is more appropriate for
management frames that need immediate handling
4. **Similar to previous backported fixes**: Looking at the similar
commits, commit #1 (fca9615f1a43) which fixed queue handling for
loopback packets was backported. This current fix addresses a similar
class of queue assignment issues.
5. **No architectural changes**: The fix uses existing infrastructure
(MT_TXQ_PSD queue) and existing helper functions
(ieee80211_is_deauth). It doesn't introduce new features or change
any APIs.
6. **Prevents resource exhaustion**: The bug can lead to hardware queue
exhaustion which is a serious issue in production AP deployments.
This makes it an important fix for stable kernels.
The code change shows that previously, only non-bufferable MMPDUs were
assigned to the PSD queue, but deauth frames (which are technically
bufferable) were getting stuck in regular data queues when sent to
powersave clients. This fix ensures deauth frames bypass the normal
buffering mechanism and get transmitted promptly via the PSD queue.
drivers/net/wireless/mediatek/mt76/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 513916469ca2f..dc9bf2fff51bb 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -617,7 +617,8 @@ mt76_txq_schedule_pending_wcid(struct mt76_phy *phy, struct mt76_wcid *wcid,
if ((dev->drv->drv_flags & MT_DRV_HW_MGMT_TXQ) &&
!(info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP) &&
!ieee80211_is_data(hdr->frame_control) &&
- !ieee80211_is_bufferable_mmpdu(skb))
+ (!ieee80211_is_bufferable_mmpdu(skb) ||
+ ieee80211_is_deauth(hdr->frame_control)))
qid = MT_TXQ_PSD;
q = phy->q_tx[qid];
--
2.39.5
More information about the Linux-mediatek
mailing list