[OpenWrt-Devel] AA on brcm47xx: Unhandled kernel unaligned access

[Jonas Gorski]

On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau <nbd at openwrt.org> wrote:
> On 2014-07-14 16:42, Rafał Miłecki wrote:
>> On 21 June 2014 18:36, Nikolai Zhubr <n-a-zhubr at yandex.ru> wrote:
>>> [  637.430000] ------------[ cut here ]------------
>>> [  637.440000] WARNING: at net/core/dev.c:2194
>>> skb_warn_bad_offload+0xc0/0xe8()
>>> [  637.450000] b44: caps=(0x0000000000004000, 0x0000000000000000) len=1500
>>> data_len=0 gso_size=53118 gso_type=59551 ip_summed=0
>>> [  637.460000] Modules linked in: pppoe ppp_async iptable_nat b43legacy b43
>>> pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE
>>> cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac
>>> xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc
>>> nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc
>>> nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT
>>> ip_tables crc_ccitt compat ip6t_REJECT ip6table_raw ip6table_mangle
>>> ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack
>>> nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher leds_gpio gpio_button_hotplug tg3
>>> hwmon bgmac b44 ptp pps_core
>>> [  637.520000] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.10.36 #1
>>> [  637.520000] Stack : 00000000 00000000 00000000 00000000 8030d552 00000036
>>> 818201d0 00000008
>>>           8026cfd0 802bb23b 00000003 8030cd00 818201d0 00000008 802b76e4
>>> 00000000
>>>           802b76dc 8001c118 00000003 80019ad8 80293ecc 00000008 8026e870
>>> 8182bc5c
>>>           00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> 00000000
>>>           00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> 8182bbe8
>>>           ...
>>> [  637.560000] Call Trace:
>>> [  637.560000] [<80010bb4>] show_stack+0x48/0x70
>>> [  637.570000] [<80019bd4>] warn_slowpath_common+0x78/0xa8
>>> [  637.570000] [<80019c30>] warn_slowpath_fmt+0x2c/0x38
>>> [  637.580000] [<801b27dc>] skb_warn_bad_offload+0xc0/0xe8
>>> [  637.580000] [<801b6390>] __skb_gso_segment+0x50/0xec
>>> [  637.590000] [<801de0dc>] ip_forward_finish+0x108/0x1bc
>>> [  637.590000] [<801b386c>] __netif_receive_skb_core+0x46c/0x52c
>>> [  637.600000] [<81acc16c>] 0x81acc16c
>>> [  637.600000]
>>> [  637.600000] ---[ end trace 2c2a6a28d6589bcc ]---
>>
>> Any idea anyone? Does above mean b44 provided a corrupted packet? Or
>> some wrong pointer?
> It looks to me like the hardware is overwriting the skb shared info (at
> the end of the skb data buffer), possibly because the configured maximum
> frame length may be too big for the buffer.
>
> If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to
> the maximum frame length, not the maximum buffer length - and in the
> code, it's being fed with the maximum buffer length.
> This would allow the hardware to receive slightly oversized frames which
> can corrupt the skb.

Since there is a public datasheet[1], this is easily verifiable, and
it looks you are right:

"Receive Maximum Length Register (RcvLength, Offset 0x404):

The value stored in this register specifies the largest valid Ethernet
Frame to be received."

The same is true for the XmtMaxLength register, which is also set "too
large" (it defaults to 1518).


Jonas

[1]: https://www.broadcom.com/collateral/pg/440X-PG02-R.pdf
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel