<div dir="ltr">It is most likely just insufficient locking. active_txq_lock is per AC, can't protect local->aql_total_pending_airtime against racing conditions<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2019 at 3:17 AM Johannes Berg <<a href="mailto:johannes@sipsolutions.net">johannes@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2019-11-08 at 12:10 +0100, Toke Høiland-Jørgensen wrote:<br>
<br>
> Right, bugger. I was thinking maybe there's a case where skbs can be<br>
> cloned (and retain the tx_time_est field) and then released twice? <br>
<br>
They could be cloned, but I don't see how that'd be while *inside* the<br>
stack and then they get reported twice - unless the driver did something<br>
like that?<br>
<br>
I mean, TCP surely does that for example, but it's before we even get to<br>
mac80211.<br>
<br>
> Or<br>
> maybe somewhere that steps on the skb->cb field in some other way?<br>
> Couldn't find anything obvious on a first perusal of the TX path code,<br>
> but maybe you could think of something?<br>
<br>
No, sorry. But I also didn't actually look at the driver at all.<br>
<br>
> Otherwise I guess we'll be forced to go and do some actual,<br>
> old-fashioned debugging ;)<br>
<br>
:)<br>
<br>
johannes<br>
<br>
</blockquote></div>