Search Linux Wireless

Re: brcmf_txfinalize misses 802.1x packet leading to infinite WARNINGs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22 September 2016 at 14:24, Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
> On 09/22/2016 01:59 PM, Rafał Miłecki wrote:
>>
>> And again...
>>
>> I decided to focus on brcmf_flowring_delete a bit more.
>>
>> As I can see flowrings are created and removed from time to time, in most
>> cases
>> they are empty when being deleted. When they are not, things go wrong. In
>> below
>> log you can see brcmfmac removing flowring that got 8 skb packets.
>>
>> First some summary, of what was already partially noticed in previous
>> e-mail:
>> 1) brcmf_flowring_delete calls brcmu_pkt_buf_free_skb directly bypassing
>>    brcmf_txfinalize. It means tracing 802.1x packets and counting TX
>> errors is
>>    broken.
>> 2) After freeing skb (as the result of brcmf_flowring_delete) there will
>> still
>>    an IRQ, MSGBUF_TYPE_TX_STATUS and call to the brcmf_txfinalize. That's
>>    definitely unexpected as brcmf_txfinalize will be operating on skb that
>> was
>>    already freed.
>>
>> Now, there is something new that looks even worse. Sometimes
>> brcmf_txfinalize
>> may be called multiple times for the same skb! Take a close look at my
>> log.
>> It was called twice for skb c64a5a80. Twice for c64a5480. Twice for
>> c64a5f00.
>> Then Linux/device rebooted itself due to amount of console messages.
>
>
> 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?




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux