On 22 September 2016 at 16:09, Rafał Miłecki <zaj...@gmail.com> wrote: > On 22 September 2016 at 14:24, Rafał Miłecki <zaj...@gmail.com> wrote: >> I got the same problem again, but this time there was only 1 skb in my >> flowring. >> That resulted in less serial console messages and no reboot. >> >> It doesn't look good. brcmf_txfinalize was called 11 times after deleting >> flowring. Everytime it was working with the same skb that was already freed. > > I'm wondering if there is some bug in flowring code. Please take a > look if my following understanding it correct. > > 1) Every skb that is supposed to reach the device gets queued on a flowring. > 2) Dequeuing means skb is not available in a flowring anymore > 3a) brcmf_msgbuf_txflow dequeues skbs to pass them to the firmware > 3b) brcmf_flowring_delete dequeues skbs to delete (free) them > > If that simple description is correct, it shouldn't be possible to skb to: > 1) Reach the firmware > *and* > 2) Get freed as part of flowring deletion > > But this is what seems to be happening in my case. We get one skb > freed on flowring deletion and then reported as transmitted (sometimes > multiple times) by the firmware. > > Maybe there is simply a race between brcmf_flowring_delete and > brcmf_msgbuf_txflow?
I can see a problem with my debugging code. It may happen brcmfmac gets skb allocated at the same address. Due to brcmf_flowring_delete bypassing brcmf_txfinalize we don't drop tracing of the old one and that results in the same packet listed twice in my debugging code. I got caught into the same trap that breaks pend_8021x_cnt counting. I believe pend_8021x_cnt related code should be moved to the place that really queues skb for the firmware to access. -- Rafał
