linux/drivers/net, branch v2.6.35

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6

2010-07-27T16:21:00Z

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: s2io: fixing DBG_PRINT() macro ath9k: fix dma direction for map/unmap in ath_rx_tasklet net: dev_forward_skb should call nf_reset net sched: fix race in mirred device removal tun: avoid BUG, dump packet on GSO errors bonding: set device in RLB ARP packet handler wimax/i2400m: Add PID & VID for Intel WiMAX 6250 ipv6: Don't add routes to ipv6 disabled interfaces. net: Fix skb_copy_expand() handling of ->csum_start net: Fix corruption of skb csum field in pskb_expand_head() of net/core/skbuff.c macvtap: Limit packet queue length ixgbe/igb: catch invalid VF settings bnx2x: Advance a module version bnx2x: Protect statistics ramrod and sequence number bnx2x: Protect a SM state change wireless: use netif_rx_ni in ieee80211_send_layer2_update

s2io: fixing DBG_PRINT() macro

2010-07-26T22:37:30Z

Patch 9e39f7c5b311a306977c5471f9e2ce4c456aa038 changed the DBG_PRINT() macro and the if clause was wrongly changed. It means that currently all the DBG_PRINT are being printed, flooding the kernel log buffer with things like: s2io: eth6: Next block at: c0000000b9c90000 s2io: eth6: In Neterion Tx routine Signed-off-by: Breno Leitao Acked-by: Sreenivasa Honnur Signed-off-by: David S. Miller

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6

2010-07-26T20:26:09Z

ath9k: fix dma direction for map/unmap in ath_rx_tasklet

2010-07-26T18:41:04Z

For edma, we should use DMA_BIDIRECTIONAL, or else use DMA_FROM_DEVICE. This is found to address "BUG at arch/x86/mm/physaddr.c:5" as described here: http://lkml.org/lkml/2010/7/14/21 Signed-off-by: Ming Lei Signed-off-by: John W. Linville

NET: declance: Fix section mismatches

2010-07-26T18:08:14Z

WARNING: drivers/net/built-in.o(.data+0x24): Section mismatch in reference from the variable dec_lance_tc_driver to the function .init.text:dec_lance_tc_probe() The variable dec_lance_tc_driver references the function __init dec_lance_tc_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, Fixing this one results in a new mismatch: WARNING: drivers/net/built-in.o(.devinit.text+0x14): Section mismatch in reference from the function dec_lance_tc_probe() to the function .init.text:dec_lance_probe() The function __devinit dec_lance_tc_probe() references a function __init dec_lance_probe(). If dec_lance_probe is only used by dec_lance_tc_probe then annotate dec_lance_probe with a matching annotation. Signed-off-by: Ralf Baechle

Merge branch 'wimax-2.6.35.y' of git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax

2010-07-25T03:51:45Z

tun: avoid BUG, dump packet on GSO errors

2010-07-25T03:47:20Z

There are still some LRO cards that cause GSO errors in tun, and BUG on this is an unfriendly way to tell the admin to disable LRO. Further, experience shows we might have more GSO bugs lurking. See https://bugzilla.kernel.org/show_bug.cgi?id=16413 as a recent example. dumping a packet will make it easier to figure it out. Replace BUG with warning+dump+drop the packet to make GSO errors in tun less critical and easier to debug. Signed-off-by: Michael S. Tsirkin Tested-by: Alex Unigovsky Acked-by: Herbert Xu Signed-off-by: David S. Miller

bonding: set device in RLB ARP packet handler

2010-07-25T03:37:48Z

After: commit 6146b1a4da98377e4abddc91ba5856bef8f23f1e Author: Jay Vosburgh Date: Tue Nov 4 17:51:15 2008 -0800 bonding: Fix ALB mode to balance traffic on VLANs the dev field in the RLB ARP packet handler was set to NULL to wildcard and accommodate balancing VLANs on top of bonds. This has the side-effect of the packet handler being called against other, non RLB-enabled bonds, and a kernel oops results when it tries to dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be set for those bonds, e.g. active-backup. With the __netif_receive_skb() changes from: commit 1f3c8804acba841b5573b953f5560d2683d2db0d Author: Andy Gospodarek Date: Mon Dec 14 10:48:58 2009 +0000 bonding: allow arp_ip_targets on separate vlans to use arp validation frames received on VLANs correctly make their way to the bond's handler, so we no longer need to wildcard the device. The oops can be reproduced by: modprobe bonding echo active-backup > /sys/class/net/bond0/bonding/mode echo 100 > /sys/class/net/bond0/bonding/miimon ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx echo +eth0 > /sys/class/net/bond0/bonding/slaves echo +eth1 > /sys/class/net/bond0/bonding/slaves echo +bond1 > /sys/class/net/bonding_masters echo balance-alb > /sys/class/net/bond1/bonding/mode echo 100 > /sys/class/net/bond1/bonding/miimon ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx echo +eth2 > /sys/class/net/bond1/bonding/slaves echo +eth3 > /sys/class/net/bond1/bonding/slaves Pass some traffic on bond0. Boom. [ Tested, behaves as advertised. I do not believe a test of the bonding mode is necessary, as there is no race between the packet handler and the bonding mode changing (the mode can only change when the device is closed). Also updated the log message to include the reproduction and full commit ids. -J ] Signed-off-by: Greg Edwards Signed-off-by: Jay Vosburgh Acked-by: Andy Gospodarek Signed-off-by: David S. Miller

wimax/i2400m: Add PID & VID for Intel WiMAX 6250

2010-07-22T21:50:34Z

This version of intel wimax device was found in my IBM ThinkPad x201 Signed-off-by: Alexey Shvetsov

macvtap: Limit packet queue length

2010-07-22T20:08:56Z

Mark Wagner reported OOM symptoms when sending UDP traffic over a macvtap link to a kvm receiver. This appears to be caused by the fact that macvtap packet queues are unlimited in length. This means that if the receiver can't keep up with the rate of flow, then we will hit OOM. Of course it gets worse if the OOM killer then decides to kill the receiver. This patch imposes a cap on the packet queue length, in the same way as the tuntap driver, using the device TX queue length. Please note that macvtap currently has no way of giving congestion notification, that means the software device TX queue cannot be used and packets will always be dropped once the macvtap driver queue fills up. This shouldn't be a great problem for the scenario where macvtap is used to feed a kvm receiver, as the traffic is most likely external in origin so congestion notification can't be applied anyway. Of course, if anybody decides to complain about guest-to-guest UDP packet loss down the track, then we may have to revisit this. Incidentally, this patch also fixes a real memory leak when macvtap_get_queue fails. Chris Wright noticed that for this patch to work, we need a non-zero TX queue length. This patch includes his work to change the default macvtap TX queue length to 500. Reported-by: Mark Wagner Signed-off-by: Herbert Xu Acked-by: Chris Wright Acked-by: Arnd Bergmann Signed-off-by: David S. Miller