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

Jonas Gorski jogo at openwrt.org
Mon Jul 14 17:46:23 EDT 2014


On Mon, Jul 14, 2014 at 11:35 PM, Rafał Miłecki <zajec5 at gmail.com> wrote:
> On 14 July 2014 18:44, Jonas Gorski <jogo at openwrt.org> wrote:
>> On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau <nbd at openwrt.org> wrote:
>>> 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).
>
> I wonder what's the point of that register if we set length per-skb
> anyway (b44_alloc_rx_skb):
> ctrl = (DESC_CTRL_LEN & RX_PKT_BUF_SZ);

As far as I understand, the hardware is capable of letting packets
span several descriptors, so if you expect to have mostly small
packets (e.g. < 600 bytes), you could save memory by only using 600
byte rx buffers, but still allowing the engine to receive full 1518
bytes frames, then split over several descriptors.


Jonas
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list