Ben Greear <greearb@xxxxxxxxxxxxxxx> writes: > On 08/02/2018 01:20 PM, Toke Høiland-Jørgensen wrote: >> Ben Greear <greearb@xxxxxxxxxxxxxxx> writes: >> >>> On 08/02/2018 12:45 PM, Toke Høiland-Jørgensen wrote: >>>> Ben Greear <greearb@xxxxxxxxxxxxxxx> writes: >>>> >>>>> This is from my hacked kernel, could be my fault. I thought the fq >>>>> guys might want to know however... >>>> >>>> Hmm, nothing obvious comes to mind; fq_flow_dequeue() just dequeues a >>>> packet from the queue; it only has two memory derefs, to fq->lock and >>>> flow->queue. Don't see why either of those should be freed at this >>>> point. >>>> >>>> Unless fq_adjust_removal() is being inlined, perhaps? Then I suppose the >>>> flow->tin reference could be the problem, if the txq_info struct was >>>> already freed; did you change anything around the handling of TXQs? >>> >>> I have worked on some stuff to fix other leaks and corruptions in ath10k related >>> to txqs, maybe that is part of this problem. My full tree is here: >>> >>> https://github.com/greearb/linux-ct-4.16 >>> >>> This bug in question is fairly repeatable on my current setup, which >>> is high speed tx + rx on a 9984 NIC, with buggy firmware that crashes >>> often in the tx path. I think the crash only happens when I rmmod the >>> driver under load, but possibly some of the fw crash cleanup logic >>> that ran previously is also involved. >> >> Yeah, if it happens under load that is consistent with packets being >> queued. >> >> It seems that mac80211 frees the netdevs of an interface before flushing >> the TXQs, which may be the cause of the bug you are seeing. Could you >> try the patch below and see if that fixes the issue? > > I've run with this for a few days, and it seems to at least not cause > any extra problems. I mostly fixed the firmware crashing I was seeing > before, so not certain it fixes the root cause of the crashes I > saw before. I'm going to roll this into my 4.16 ct kernel for wider > testing. Right, thanks for testing. I'll send a proper patch :) -Toke
