<div dir="auto">I'm pretty clueless on this,  but as a single data point, my Archer C7 has abt 21 days of uptime now, since my last update, as the single router in a 4 person household.  I've been running cake/piece of cake the whole time.<div dir="auto"><br></div><div dir="auto">Standard disclaimers apply as to clueless user not knowing if his FW version has anything to do with the issue in question, or if its connected to other things like whatever is going on with the airtime fairness.  But the comment in the third paragraph sounded interesting in light of my lack of a crash and running a SQM method, FWIW.</div><div dir="auto"><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><br></div><div class="gmail_quote">My last update was a sysupgrade to LEDE Reboot SNAPSHOT r2687-dc5f496 pretty sure date was 12-27-16.</div><div class="gmail_quote" dir="auto"><br></div><div class="gmail_quote" dir="auto"><br><blockquote class="m_-153624310824911377m_-4945432545166814551quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Today's Topics:<br>
<br>
   1. Fwd: [PATCH] mac80211: prevent skb/txq mismatch (Dave Taht)<br>
<br><br>---------- Forwarded message ----------<br>From: Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>><br>To: <a href="mailto:make-wifi-fast@lists.bufferbloat.net" target="_blank">make-wifi-fast@lists.buffe<wbr>rbloat.net</a><br>Cc: <br>Date: Thu, 12 Jan 2017 10:44:12 -0800<br>Subject: [Make-wifi-fast] Fwd: [PATCH] mac80211: prevent skb/txq mismatch<br>yea! (I think)<br>
<br>
<br>
---------- Forwarded message ----------<br>
From: Michal Kazior <<a href="mailto:michal.kazior@tieto.com" target="_blank">michal.kazior@tieto.com</a>><br>
Date: Thu, Jan 12, 2017 at 6:28 AM<br>
Subject: [PATCH] mac80211: prevent skb/txq mismatch<br>
To: <a href="mailto:johannes@sipsolutions.net" target="_blank">johannes@sipsolutions.net</a><br>
Cc: <a href="mailto:linux-wireless@vger.kernel.org" target="_blank">linux-wireless@vger.kernel.org</a><wbr>, <a href="mailto:greearb@candelatech.com" target="_blank">greearb@candelatech.com</a>,<br>
<a href="mailto:mohammed@qti.qualcomm.com" target="_blank">mohammed@qti.qualcomm.com</a>, Michal Kazior <<a href="mailto:michal.kazior@tieto.com" target="_blank">michal.kazior@tieto.com</a>><br>
<br>
<br>
Station structure is considered as not uploaded<br>
(to driver) until drv_sta_state() finishes. This<br>
call is however done after the structure is<br>
attached to mac80211 internal lists and hashes.<br>
This means mac80211 can lookup (and use) station<br>
structure before it is uploaded to a driver.<br>
<br>
If this happens (structure exists, but<br>
sta->uploaded is false) fast_tx path can still be<br>
taken. Deep in the fastpath call the sta->uploaded<br>
is checked against to derive "pubsta" argument for<br>
ieee80211_get_txq(). If sta->uploaded is false<br>
(and sta is actually non-NULL) ieee80211_get_txq()<br>
effectively downgraded to vif->txq.<br>
<br>
At first glance this may look innocent but coerces<br>
mac80211 into a state that is almost guaranteed<br>
(codel may drop offending skb) to crash because a<br>
station-oriented skb gets queued up on<br>
vif-oriented txq. The ieee80211_tx_dequeue() ends<br>
up looking at info->control.flags and tries to use<br>
txq->sta which in the fail case is NULL.<br>..........<br>
<br>______________________________<wbr>_________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferblo<wbr>at.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/make-wifi-fast</a><br></blockquote></div><br></div></div></div>