summaryrefslogtreecommitdiff
path: root/net/mac80211
diff options
context:
space:
mode:
authorBob Copeland <me@bobcopeland.com>2018-09-05 06:22:59 -0400
committerJohannes Berg <johannes.berg@intel.com>2018-09-05 12:54:27 +0200
commit6eae4a6c2be387fec41b0d2782c4fffb57159498 (patch)
tree25576d4628e9c4783624b661cc582f7488934a2a /net/mac80211
parent24f33e64fcd0d50a4b1a8e5b41bd0257aa66b0e8 (diff)
downloadlwn-6eae4a6c2be387fec41b0d2782c4fffb57159498.tar.gz
lwn-6eae4a6c2be387fec41b0d2782c4fffb57159498.zip
mac80211: fix pending queue hang due to TX_DROP
In our environment running lots of mesh nodes, we are seeing the pending queue hang periodically, with the debugfs queues file showing lines such as: 00: 0x00000000/348 i.e. there are a large number of frames but no stop reason set. One way this could happen is if queue processing from the pending tasklet exited early without processing all frames, and without having some future event (incoming frame, stop reason flag, ...) to reschedule it. Exactly this can occur today if ieee80211_tx() returns false due to packet drops or power-save buffering in the tx handlers. In the past, this function would return true in such cases, and the change to false doesn't seem to be intentional. Fix this case by reverting to the previous behavior. Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue") Signed-off-by: Bob Copeland <bobcopeland@fb.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/mac80211')
-rw-r--r--net/mac80211/tx.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 131542513c8f..25ba24bef8f5 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1894,7 +1894,7 @@ static bool ieee80211_tx(struct ieee80211_sub_if_data *sdata,
sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
if (invoke_tx_handlers_early(&tx))
- return false;
+ return true;
if (ieee80211_queue_skb(local, sdata, tx.sta, tx.skb))
return true;