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.


Reply via email to