aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/brcm47xx/patches-3.14/940-bcm47xx-yenta.patch
diff options
context:
space:
mode:
authorHauke Mehrtens <hauke@openwrt.org>2014-04-08 19:50:17 +0000
committerHauke Mehrtens <hauke@openwrt.org>2014-04-08 19:50:17 +0000
commitf762ec24cc0539e90966a7ee6936c486e27baf25 (patch)
tree11ffccb02373e0e5ab762cb7c4b59351f84da43d /target/linux/brcm47xx/patches-3.14/940-bcm47xx-yenta.patch
parent132cd136386c672ae7e9974689ff41792b539b15 (diff)
downloadupstream-f762ec24cc0539e90966a7ee6936c486e27baf25.tar.gz
upstream-f762ec24cc0539e90966a7ee6936c486e27baf25.tar.bz2
upstream-f762ec24cc0539e90966a7ee6936c486e27baf25.zip
kernel: bgmac: rework patch checking packet length
This bgmac patch was an attempt to fix/workaround bug reported in https://dev.openwrt.org/ticket/7198 noticed on WNR3500L. Patch assumed length reported by the hardware was 0 and was trying to read it until getting a different value. This was actually the opposite. Lenghts were some invalid & huge values that resulted in skb_over_panic. For example: skbuff: skb_over_panic: text:83b21074 len:57222 (...) skbuff: skb_over_panic: text:87af1024 len:43226 (...) skbuff: skb_over_panic: text:87af5024 len:8739 (...) So instead of that not-working patch checking for 0, write a new one checking for huge values. In case something like that happens, dump hardware state and drop the packet. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> git-svn-id: svn://svn.openwrt.org/openwrt/trunk@40424 3c298f89-4303-0410-b956-a3cf2f4a3e73
Diffstat (limited to 'target/linux/brcm47xx/patches-3.14/940-bcm47xx-yenta.patch')
0 files changed, 0 insertions, 0 deletions