* Re: query: bnx2 and tg3 don't check tcp and/or ip header length validity?
From: David Miller @ 2009-10-15 0:49 UTC (permalink / raw)
To: william.allen.simpson; +Cc: netdev
In-Reply-To: <4AD66F84.2010703@gmail.com>
This is transmit, and the packets can only come from the Linux
TCP stack, not some external entity.
You're being way too anal here, and adding these checks to
drivers would be just a lot of rediculious bloat.
^ permalink raw reply
* Re: query: bnx2 and tg3 don't check tcp and/or ip header length validity?
From: William Allen Simpson @ 2009-10-15 0:40 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <1255555458.20869.221.camel@nseg_linux_HP1.broadcom.com>
Michael Chan wrote:
> The option length is needed by the hardware to segment a TSO packet into
> proper MTU-sized packets. You'll get malformed packets if the TSO
> header is bad. Setting it to zero perhaps can make these bad packets
> more deterministic, but I don't know for sure.
>
Malformed packets are unlikely (I'll use unlikely() on the test), but
I've seen a lot of unlikely things happen over the years. When I was
concourse manager at Interop '91, a bad Portmaster build wouldn't pass
packets through one kind of router (3com); but it passed through all
the others! Turned out, *most* routers didn't check the IP version
and IHL fields. Shocking!
When we were designing IPv6 in '93, we had to use new IEEE numbers, etc.
(instead of the IP version and IHL) to distinguish the new version.
Otherwise, various printers crashed....
Unless there's a clearly documented check earlier in the code path (and
there's nothing documented here), always re-check everything. (Also,
never forget cosmic radiation....) Remember, from a driver developer's
perspective, the hardware always fails. (And from a hardware viewpoint,
the software is always bad.)
^ permalink raw reply
* [PATCH] virtio_net: use dev_kfree_skb_any() in free_old_xmit_skbs()
From: Eric Dumazet @ 2009-10-15 0:36 UTC (permalink / raw)
To: Massimo Cetra
Cc: Massimo Cetra, David Miller, rjw-KKrjLPT3xs0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4AD62626.6010709-BBpJ+9iBSNKonA0d6jMUrA@public.gmane.org>
Massimo Cetra a écrit :
> Eric,
> thanks for the patch.
> The problem didn't arise again and i haven't seen any warning like that
> on both servers where that problem was happening more frequently.
>
> I would say that it's fixed and if it's not, i'll let you know as soon
> as it happens again.
>
Thanks Massimo, I think patch is reasonably safe and should be taken as is :
[PATCH] virtio_net: use dev_kfree_skb_any() in free_old_xmit_skbs()
Because netpoll can call netdevice start_xmit() method with
irqs disabled, drivers should not call kfree_skb() from
their start_xmit(), but use dev_kfree_skb_any() instead.
Oct 8 11:16:52 172.30.1.31 [113074.791813] ------------[ cut here ]------------
Oct 8 11:16:52 172.30.1.31 [113074.791813] WARNING: at net/core/skbuff.c:398 \
skb_release_head_state+0x64/0xc8()
Oct 8 11:16:52 172.30.1.31 [113074.791813] Hardware name:
Oct 8 11:16:52 172.30.1.31 [113074.791813] Modules linked in: netconsole ocfs2 jbd2 quota_tree \
ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs crc32c drbd cn loop \
serio_raw psmouse snd_pcm snd_timer snd soundcore snd_page_alloc virtio_net pcspkr parport_pc parport \
i2c_piix4 i2c_core button processor evdev ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_snapshot \
dm_mod ide_cd_mod cdrom ata_generic ata_piix virtio_blk libata scsi_mod piix ide_pci_generic ide_core \
virtio_pci virtio_ring virtio floppy thermal fan thermal_sys [last unloaded: netconsole]
Oct 8 11:16:52 172.30.1.31 [113074.791813] Pid: 11132, comm: php5-cgi Tainted: G W \
2.6.31.2-vserver #1
Oct 8 11:16:52 172.30.1.31 [113074.791813] Call Trace:
Oct 8 11:16:52 172.30.1.31 [113074.791813] <IRQ> [<ffffffff81253cd5>] ? \
skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253cd5>] ? skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81049ae1>] ? warn_slowpath_common+0x77/0xa3
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253cd5>] ? skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253a1a>] ? __kfree_skb+0x9/0x7d
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa01cb139>] ? free_old_xmit_skbs+0x51/0x6e \
[virtio_net]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa01cbc85>] ? start_xmit+0x26/0xf2 [virtio_net]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8126934f>] ? netpoll_send_skb+0xd2/0x205
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa0429216>] ? write_msg+0x90/0xeb [netconsole]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81049f06>] ? __call_console_drivers+0x5e/0x6f
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8102b49d>] ? kvm_clock_read+0x4d/0x52
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8104a082>] ? release_console_sem+0x115/0x1ba
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8104a632>] ? vprintk+0x2f2/0x34b
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8106b142>] ? vx_update_load+0x18/0x13e
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81308309>] ? printk+0x4e/0x5d
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8102b49d>] ? kvm_clock_read+0x4d/0x52
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81070b62>] ? getnstimeofday+0x55/0xaf
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81062683>] ? ktime_get_ts+0x21/0x49
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff810626b7>] ? ktime_get+0xc/0x41
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81062788>] ? hrtimer_interrupt+0x9c/0x146
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81024a4b>] ? smp_apic_timer_interrupt+0x80/0x93
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81011663>] ? apic_timer_interrupt+0x13/0x20
Oct 8 11:16:52 172.30.1.31 [113074.791813] <EOI> [<ffffffff8130a9eb>] ? _spin_unlock_irq+0xd/0x31
Reported-and-tested-by: Massimo Cetra <mcetra-BBpJ+9iBSNKonA0d6jMUrA@public.gmane.org>
Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=14378
---
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8d00976..54bf091 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -454,7 +454,7 @@ static unsigned int free_old_xmit_skbs(struct virtnet_info *vi)
vi->dev->stats.tx_bytes += skb->len;
vi->dev->stats.tx_packets++;
tot_sgs += skb_vnet_hdr(skb)->num_sg;
- kfree_skb(skb);
+ dev_kfree_skb_any(skb);
}
return tot_sgs;
}
^ permalink raw reply related
* Re: PF_RING: Include in main line kernel?
From: Eric Dumazet @ 2009-10-15 0:25 UTC (permalink / raw)
To: David Miller; +Cc: deri, shemminger, brad.doctor, netdev
In-Reply-To: <20091014.132756.231458769.davem@davemloft.net>
David Miller a écrit :
> From: Luca Deri <deri@ntop.org>
> Date: Wed, 14 Oct 2009 22:17:30 +0200
>
>> Another reason, is that having a hook in dev.c, device drivers can
>> pass PF_RING packets directly without going through the standard
>> kernel mechanisms. For instance I have developed some drivers that if
>> they detect the presence of PF_RING, pass received packets directly to
>> PF_RING instead of going with NAPI.
>
> There is absolutely no reason to do this.
>
> If the existing infrastructure isn't good or fast enough,
> fix it, don't bypass it.
Indeed. IMHO PF_RING seems a huge pile of hacks to me, that would need
a lot of cleanup work before inclusion.
I had problems with past af_packet mmap implementation on ia32, because
not enough high order pages where available in lowmem.
"tcpdump -s 0" could trigger OOM conditions on loaded machines, not sure
it is still the case after commit 719bfeaae8104fca4ca5d47c02592b08682f14fa
(packet: avoid warnings when high-order page allocation fails)
If mmap() can only use 4K pages, are we still able to capture >4K packets ?
I'll check this.
^ permalink raw reply
* VLAN rx acceleration bypasses bridge
From: Maxime Bizon @ 2009-10-14 23:58 UTC (permalink / raw)
To: Patrick McHardy, shemminger; +Cc: netdev
Hi Patrick, Stephen & all,
If I do:
# vconfig add eth0 100
# brctl addbr br0
# brctl addif br0 eth0
Then eth0.100 gets no more packet and br0.100 should be used instead to
get tagged packets.
But, if vlan rx acceleration is enabled on eth0, then vlan 100 packets
no longer go through bridge, and eth0.100 is to be used instead.
This is fixable, but I'm not sure which behavior is preferred ?
In case we prefer the first one, how could someone bridge untagged
packets from eth0 with some tagged packets from eth1, and some tagged
packets from eth0 with untagged packets from eth1 ?
Something like this, which currently works when vlan rx accel is on:
# vconfig add eth0 100
# vconfig add eth1 100
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1.100
# brctl addbr br1
# brctl addif br1 eth0.100
# brctl addif br1 eth1
Regards,
--
Maxime
^ permalink raw reply
* Re: [net-next 0/8] bnx2x: Device Control Channel bug fixes
From: David Miller @ 2009-10-14 23:57 UTC (permalink / raw)
To: eilong; +Cc: netdev
In-Reply-To: <20091014.150922.64618889.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 14 Oct 2009 15:09:22 -0700 (PDT)
> Applied to net-next-2.6, which is where this likely belongs.
Eilon I somehow screwed up this patch set, and largely that is
because the firmware patch was too large for the list and therefore
it didn't end up in patchwork.
I tried to force in the private copy you sent me into the bundle
I applied, but I screwed that up somehow.
Could you please privately send me this whole patch set again so I can
try to apply it properly?
Thanks!
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] be2net: Add support for next generation of BladeEngine device
From: David Miller @ 2009-10-14 23:33 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091014.152402.92489105.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 14 Oct 2009 15:24:02 -0700 (PDT)
> From: Ajit Khaparde <ajitk@serverengines.com>
> Date: Wed, 14 Oct 2009 17:54:09 +0530
>
>> Add new PCI ids to support next generation of BladeEnigne device.
>>
>> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
>
> Applied.
I have to revert your changes, how did this even build for you?
In file included from drivers/net/benet/be_cmds.c:18:
drivers/net/benet/be.h:45:1: warning: "BE_DEVICE_ID1" redefined
drivers/net/benet/be.h:44:1: warning: this is the location of the previous definition
drivers/net/benet/be.h:48:1: warning: "OC_DEVICE_ID2" redefined
drivers/net/benet/be.h:47:1: warning: this is the location of the previous definition
Well, obviously, since in your patch:
#define BE_VENDOR_ID 0x19a2
#define BE_DEVICE_ID1 0x211
+#define BE_DEVICE_ID1 0x221
#define OC_DEVICE_ID1 0x700
#define OC_DEVICE_ID2 0x701
+#define OC_DEVICE_ID2 0x710
drivers/net/benet/be.h:56: error: 'OC_DEVICE_ID3' undeclared (first use in this function)
drivers/net/benet/be.h:58: error: 'BE_DEVICE_ID2' undeclared (first use in this function)
The mistake is obvious, and you provably didn't even compile check
these changes.
How can I possibly take your patches seriously when it is clear how
incredibly careless you are being here?
^ permalink raw reply
* Re: PF_RING: Include in main line kernel?
From: Ben Greear @ 2009-10-14 23:29 UTC (permalink / raw)
To: David Miller; +Cc: zbr, deri, shemminger, brad.doctor, netdev
In-Reply-To: <20091014.144923.112167161.davem@davemloft.net>
On 10/14/2009 02:49 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Wed, 14 Oct 2009 14:27:45 -0700
>
>> Maybe something similar to the attached patch?
>
> This is not something I'm interested in applying.
>
> It makes implementing proprietary complete networking stacks
> for Linux way too easy.
>
> Instead I'd rather have a GPL exported function that allows indication
> of consumption somehow.
This would mean one hard-coded hook for every application that wanted
this feature, or is there some way to have a gpl_ptype_all?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2009-10-14 22:50 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) PHY drivers need to be linked in before the rest, otherwise built-in
drivers won't probe properly since the PHY driver they need isn't
ready and registered yet.
2) znet driver was taking IRQ locks around calls that sleep.
3) udp_poll() can race with recvmsg() in accessing the receive buffer
SKB queue, fix from Eric Dumazet.
4) netlink fails to fully ininitialize a struct copied back to
user space, fix from Jiri Pirko
5) 3c574_cs multicast handling needs spin locking, from Ken Kawasaki
6) Cisco HDLC handshaking is busted, fix from Krzysztof Halasa.
7) Wireless bug fixes via John Linville
8) netxen needs to use resource_size_t as type for resource values.
Fix from Dhanajay Phadke
9) Pegasus driver registers erroneously for bluetooth adapters,
fix from Chris Rankin
10) OF network drivers don't detect correctly when built modular
because they lack MODULE_DEVICE_TABLE() entries.
11) Fix IXP 2000 driver build, from Vincent Sanders.
Please pull, thanks a lot!
The following changes since commit 80f506918fdaaca6b574ba931536a58ce015c7be:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alan Cox (3):
libertas: fix build
libertas: fix build
ethoc: fix warning from 32bit build
Albert Herranz (1):
b43: do not stack-allocate pio rx/tx header and tail buffers
Anton Vorontsov (1):
net: Fix OF platform drivers coldplug/hotplug when compiled as modules
Ben Hutchings (1):
acenic: Pass up error code from ace_load_firmware()
Bjorn Helgaas (1):
iwlwifi: use %pM for formatted MAC addresses
Chris Rankin (1):
net: Teach pegasus driver to ignore bluetoother adapters with clashing Vendor:Product IDs
Dave Mitchell (1):
ibm_newemac: Added 16K Tx FIFO size support for EMAC4
David S. Miller (4):
znet: Don't claim DMA lock around free_dma() calls.
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
net: Link in PHY drivers before others.
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Dhananjay Phadke (1):
netxen: fix pci bar mapping
Dmitry Artamonow (1):
irda/sa1100_ir: check return value of startup hook
Eric Dumazet (3):
net: Add patchwork URL to MAINTAINERS
net: Fix struct sock bitfield annotation
udp: Fix udp_poll() and ioctl()
Felix Fietkau (1):
mac80211: fix logic error ibss merge bssid check
Giuseppe Cavallaro (1):
net: add support for STMicroelectronics Ethernet controllers.
Jay Sternberg (1):
iwlwifi: incorrect method used for finding valid OTP blocks
Jiri Pirko (1):
netlink: fix typo in initialization
Johannes Berg (5):
mac80211: fix vlan and optimise RX
cfg80211: fix netns error unwinding bug
mac80211: fix ibss race
b43: fix ieee80211_rx() context
mac80211: document ieee80211_rx() context requirement
John Bonesio (1):
net/fec_mpc52xx: Fix kernel panic on FEC error
Ken Kawasaki (1):
3c574_cs: spin_lock the set_multicast_list function
Krzysztof Halasa (1):
WAN: fix Cisco HDLC handshaking.
Larry Finger (1):
b43: Fix PPC crash in rfkill polling on unload
Michael Buesch (2):
b43: Don't use struct wldev after detach.
b43: Protect sanity check against physical device removal
Randy Dunlap (1):
net: ks8851_mll uses mii interfaces
Reinette Chatre (2):
iwlwifi: fix compile warning
iwlagn: fix compile warning in iwl5000_gain_computation
Roel Kluin (2):
mac80211: fix ADM8211_SYNCTL_RFtype define
mac80211: use kfree_skb() to free struct sk_buff pointers
Ron Mercer (7):
qlge: Fix RSS hashing values.
qlge: Fix frame routing issue related to bonding.
qlge: Fix frame routing for multicast frames.
qlge: Fix RX multicast filter settings.
qlge: Fix chip reset process.
qlge: Restore rx mode after internal reset.
qlge: Add disable/enable firmare irqs to handler.
Shreyas Bhatewara (1):
net: VMware virtual Ethernet NIC driver: vmxnet3
Sriram (1):
TI DaVinci EMAC: Clear statistics register properly.
Vincent Sanders (1):
net: Fix IXP 2000 network driver building.
Wey-Yi Guy (2):
iwlwifi: fix EEPROM enhance tx power offset
iwlwifi: change the order of freeing memory
Willy Tarreau (1):
tcp: fix tcp_defer_accept to consider the timeout
Wolfram Sang (1):
include/linux/netdevice.h: fix nanodoc mismatch
françois romieu (1):
r8169: partial support and phy init for the 8168d
jamal (1):
pkt_sched: pedit use proper struct
MAINTAINERS | 8 +
drivers/net/Kconfig | 11 +
drivers/net/Makefile | 10 +-
drivers/net/acenic.c | 3 +-
drivers/net/can/sja1000/sja1000_of_platform.c | 1 +
drivers/net/davinci_emac.c | 36 +-
drivers/net/ethoc.c | 3 +-
drivers/net/fec_mpc52xx.c | 6 -
drivers/net/fec_mpc52xx_phy.c | 1 +
drivers/net/fs_enet/fs_enet-main.c | 1 +
drivers/net/fs_enet/mii-bitbang.c | 1 +
drivers/net/fs_enet/mii-fec.c | 1 +
drivers/net/fsl_pq_mdio.c | 1 +
drivers/net/gianfar.c | 4 +-
drivers/net/ibm_newemac/core.c | 9 +-
drivers/net/ibm_newemac/emac.h | 1 +
drivers/net/irda/sa1100_ir.c | 7 +-
drivers/net/ixp2000/enp2611.c | 18 +-
drivers/net/ixp2000/ixpdev.c | 11 +
drivers/net/netxen/netxen_nic_main.c | 3 +-
drivers/net/pcmcia/3c574_cs.c | 13 +-
drivers/net/phy/mdio-gpio.c | 1 +
drivers/net/qlge/qlge.h | 10 +-
drivers/net/qlge/qlge_main.c | 97 +-
drivers/net/qlge/qlge_mpi.c | 93 +
drivers/net/r8169.c | 987 +++++++++-
drivers/net/stmmac/Kconfig | 53 +
drivers/net/stmmac/Makefile | 4 +
drivers/net/stmmac/common.h | 330 ++++
drivers/net/stmmac/descs.h | 163 ++
drivers/net/stmmac/gmac.c | 693 +++++++
drivers/net/stmmac/gmac.h | 204 ++
drivers/net/stmmac/mac100.c | 517 +++++
drivers/net/stmmac/mac100.h | 116 ++
drivers/net/stmmac/stmmac.h | 98 +
drivers/net/stmmac/stmmac_ethtool.c | 395 ++++
drivers/net/stmmac/stmmac_main.c | 2204 +++++++++++++++++++++
drivers/net/stmmac/stmmac_mdio.c | 217 +++
drivers/net/stmmac/stmmac_timer.c | 140 ++
drivers/net/stmmac/stmmac_timer.h | 41 +
drivers/net/usb/pegasus.c | 13 +
drivers/net/usb/pegasus.h | 6 +-
drivers/net/vmxnet3/Makefile | 35 +
drivers/net/vmxnet3/upt1_defs.h | 96 +
drivers/net/vmxnet3/vmxnet3_defs.h | 535 ++++++
drivers/net/vmxnet3/vmxnet3_drv.c | 2556 +++++++++++++++++++++++++
drivers/net/vmxnet3/vmxnet3_ethtool.c | 566 ++++++
drivers/net/vmxnet3/vmxnet3_int.h | 389 ++++
drivers/net/wan/hdlc_cisco.c | 18 +-
drivers/net/wireless/adm8211.h | 2 +-
drivers/net/wireless/b43/b43.h | 168 +-
drivers/net/wireless/b43/leds.c | 4 +-
drivers/net/wireless/b43/leds.h | 4 +-
drivers/net/wireless/b43/main.c | 7 +-
drivers/net/wireless/b43/pio.c | 78 +-
drivers/net/wireless/b43/xmit.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-3945-rs.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 23 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 20 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 2 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
drivers/net/wireless/libertas/cmdresp.c | 1 +
drivers/net/znet.c | 8 -
include/linux/netdevice.h | 2 +-
include/net/mac80211.h | 2 +
include/net/sock.h | 10 +-
net/ipv4/tcp_minisocks.c | 1 +
net/ipv4/udp.c | 73 +-
net/mac80211/ibss.c | 4 +-
net/mac80211/rx.c | 12 +-
net/mac80211/sta_info.c | 2 +
net/mac80211/tx.c | 3 +-
net/mac80211/util.c | 4 +-
net/sched/act_pedit.c | 2 +-
net/sched/cls_api.c | 2 +-
net/wireless/nl80211.c | 3 +-
80 files changed, 10835 insertions(+), 345 deletions(-)
create mode 100644 drivers/net/stmmac/Kconfig
create mode 100644 drivers/net/stmmac/Makefile
create mode 100644 drivers/net/stmmac/common.h
create mode 100644 drivers/net/stmmac/descs.h
create mode 100644 drivers/net/stmmac/gmac.c
create mode 100644 drivers/net/stmmac/gmac.h
create mode 100644 drivers/net/stmmac/mac100.c
create mode 100644 drivers/net/stmmac/mac100.h
create mode 100644 drivers/net/stmmac/stmmac.h
create mode 100644 drivers/net/stmmac/stmmac_ethtool.c
create mode 100644 drivers/net/stmmac/stmmac_main.c
create mode 100644 drivers/net/stmmac/stmmac_mdio.c
create mode 100644 drivers/net/stmmac/stmmac_timer.c
create mode 100644 drivers/net/stmmac/stmmac_timer.h
create mode 100644 drivers/net/vmxnet3/Makefile
create mode 100644 drivers/net/vmxnet3/upt1_defs.h
create mode 100644 drivers/net/vmxnet3/vmxnet3_defs.h
create mode 100644 drivers/net/vmxnet3/vmxnet3_drv.c
create mode 100644 drivers/net/vmxnet3/vmxnet3_ethtool.c
create mode 100644 drivers/net/vmxnet3/vmxnet3_int.h
^ permalink raw reply
* Re: TCP_DEFER_ACCEPT is missing counter update
From: David Miller @ 2009-10-14 22:43 UTC (permalink / raw)
To: w; +Cc: ja, netdev, eric.dumazet
In-Reply-To: <20091014201706.GA24298@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Wed, 14 Oct 2009 22:17:06 +0200
> Hello Julian,
>
> On Wed, Oct 14, 2009 at 10:27:50AM +0300, Julian Anastasov wrote:
>> The semantic 'TCP_DEFER_ACCEPT extends the period after ACK'
>> is good, you can tune it together with TCP_SYNCNT, to
>> extend or not to extend the period. What happens on
>> TCP_DEFER_ACCEPT expiration after ACK - we all prefer to
>> see FIN, so we have to wait someone to come with new
>> implementation.
>
> Well, too much complicated for very little gain IMHO.
For now I'm pushing Willy's change into Linus's tree.
After more discussion we can revert if necessary.
I won't submit this to -stable until the discussion is fully resolved.
Thanks!
^ permalink raw reply
* Re: bisect results of MSI-X related panic (help!)
From: Brandeburg, Jesse @ 2009-10-14 22:30 UTC (permalink / raw)
To: Tejun Heo
Cc: Jesse Brandeburg, Frans Pop, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Ingo Molnar, hpa@zytor.com
In-Reply-To: <4AD3E875.5040800@kernel.org>
On Mon, 12 Oct 2009, Tejun Heo wrote:
> Can you please apply the following patch and try to retrigger the
> panic?
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index c166019..f5a1482 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -63,6 +63,9 @@ void dynamic_irq_cleanup(unsigned int irq)
> struct irq_desc *desc = irq_to_desc(irq);
> unsigned long flags;
>
> + printk("XXX dynamic_irq_cleanup() called on %u\n", irq);
> + dump_stack();
> +
> if (!desc) {
> WARN(1, KERN_ERR "Trying to cleanup invalid IRQ%d\n", irq);
> return;
I'm working on it, but now that I've added a bunch of debug including the
above printk, my system panics (with a stack protector canary overwrite)
when loading the first network adapter with 30+ MSI-X vectors. I can boot
single user mode and bring up netconsole, but then as soon as I brought up
the first port with lots of MSI-X vectors, the system hard locks, no panic
message.
I have a bit of a theory that the node = -1 (numa_node) stuff might be
playing some havoc with the code in numa_migrate.c. I'm not sure if that
is contributing, but the code in there doesn't seem written to handle node
= - 1 very well. As in I never see it do an smp_processor_id at the
bottom before accessing the node value.
Not sure if that is relevant, but I wanted to mention it before I went
home.
What next? I made it worse so I guess that is something.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] be2net: Bump the driver version number.
From: David Miller @ 2009-10-14 22:24 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091014122436.GA12216@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Wed, 14 Oct 2009 17:54:46 +0530
> Bump the version number to 2.101.260
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] be2net: Add support for next generation of BladeEngine device
From: David Miller @ 2009-10-14 22:24 UTC (permalink / raw)
To: ajitk; +Cc: netdev
In-Reply-To: <20091014122358.GA11905@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Wed, 14 Oct 2009 17:54:09 +0530
> Add new PCI ids to support next generation of BladeEnigne device.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: add support for STMicroelectronics Ethernet controllers.
From: David Miller @ 2009-10-14 22:14 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: eric.dumazet, netdev
In-Reply-To: <4AD57693.1010604@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 14 Oct 2009 08:58:27 +0200
>>From d370c0d34c2cfe20de94c05e243ab761e316ab4d Mon Sep 17 00:00:00 2001
> From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Date: Mon, 12 Oct 2009 11:11:06 +0200
> Subject: [PATCH] net: add support for STMicroelectronics Ethernet controllers.
>
> This is the driver for the ST MAC 10/100/1000 on-chip Ethernet
> controllers (Synopsys IP blocks).
>
> Driver documentation:
> o http://stlinux.com/drupal/kernel/network/stmmac
> Revisions:
> o http://stlinux.com/drupal/kernel/network/stmmac-driver-revisions
> Performances:
> o http://stlinux.com/drupal/benchmarks/networking/stmmac
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH -mmotm] net: ks8851_mll uses mii interfaces
From: David Miller @ 2009-10-14 22:11 UTC (permalink / raw)
To: randy.dunlap; +Cc: akpm, netdev, linux-kernel, david.choi
In-Reply-To: <20091014145905.219416bb.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 14 Oct 2009 14:59:05 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> ks8851_mll uses mii interfaces so it needs to select MII.
>
> ks8851_mll.c:(.text+0xf95ac): undefined reference to `generic_mii_ioctl'
> ks8851_mll.c:(.text+0xf96a0): undefined reference to `mii_ethtool_gset'
> ks8851_mll.c:(.text+0xf96fa): undefined reference to `mii_ethtool_sset'
> ks8851_mll.c:(.text+0xf9754): undefined reference to `mii_link_ok'
> ks8851_mll.c:(.text+0xf97ae): undefined reference to `mii_nway_restart'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: David Choi <david.choi@micrel.com>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH v2] net/fec_mpc52xx: Fix kernel panic on FEC error
From: David Miller @ 2009-10-14 22:10 UTC (permalink / raw)
To: grant.likely; +Cc: bones, netdev, linuxppc-dev
In-Reply-To: <20091014174224.29221.18830.stgit@angua>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Wed, 14 Oct 2009 11:43:43 -0600
> From: John Bonesio <bones@secretlab.ca>
>
> The MDIO bus cannot be accessed at interrupt context, but on an FEC
> error, the fec_mpc52xx driver reset function also tries to reset the
> PHY. Since the error is detected at IRQ context, and the PHY functions
> try to sleep, the kernel ends up panicking.
>
> Resetting the PHY on an FEC error isn't even necessary. This patch
> solves the problem by removing the PHY reset entirely.
>
> Signed-off-by: John Bonesio <bones@secretlab.ca>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Applied, thanks.
^ permalink raw reply
* Re: [net-next 0/8] bnx2x: Device Control Channel bug fixes
From: David Miller @ 2009-10-14 22:09 UTC (permalink / raw)
To: eilong; +Cc: netdev
In-Reply-To: <1255532825.25030.35.camel@lb-tlvb-eilong>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Wed, 14 Oct 2009 17:07:05 +0200
> This bnx2x patch series is fixing some bugs that relates to the Device
> Control Channel (DCC) code. There are actually 3 different failures:
>
> 1. When the fairness initial value was set to zero, the device could not
> be enabled. This is caused since zero indicated that the mechanism is
> disabled, and the code (both FW and driver) was not ready to allow
> enabling it at run time. This patch requires replacing the FW - to allow
> easier review, it is split to 3 patches:
> P1: adding the new FW
> P2: the actually patch
> P3: removing the old FW
>
> 2. Races when loading/unloading the driver when DCC link enable/disable
> commands are received. There were 3 different races:
> P4: The state of the driver which indicates if it is loaded or
> not was also used to signal if its link is enabled/disabled by
> DCC
> P5: The FW commands to acknowledge the DCC command and
> loading/unloading the driver run over each other
> P6: Setting/clearing the MAC address and the FW filtering rules
>
> 3. P7: Reporting the maximal BW as the link speed
>
> Patch number 8 is the version update.
>
> The patches were made based on net-next. Since those are bug fixes,
> please let me know if I should send them based on net-2.6 as well.
Applied to net-next-2.6, which is where this likely belongs.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/5] Phonet: basic routing support
From: David Miller @ 2009-10-14 22:08 UTC (permalink / raw)
To: remi; +Cc: netdev
In-Reply-To: <06dcdf33b2a0132b2a05c3220735a81e@chewa.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Wed, 14 Oct 2009 12:47:34 +0200
>
> This patchset provides rudimentary support for routing Phonet packets.
> Configuration is done with the common rtnetlink infrastructure.
>
> This is useful when there is more than one Phonet interface in the same
> namespace,
> e.g. a serial bus to a cellular modem and a USB gadget function to a PC.
Looks good, applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [RFC][PATCH] pkt_sched: skbedit add support for setting mark
From: David Miller @ 2009-10-14 22:08 UTC (permalink / raw)
To: hadi; +Cc: denys, alexander.h.duyck, netdev
In-Reply-To: <1255523114.21940.14.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Wed, 14 Oct 2009 08:25:14 -0400
>
> Here are two patches, one for kernel and one for iproute2.
> I have tested it and it works fine. Unless there are objections, I
> would like to make a formal submission of this.
This patch doesn't apply.
You forgot to add the new files when you checked them into your
tree.
^ permalink raw reply
* [PATCH -mmotm] net: ks8851_mll uses mii interfaces
From: Randy Dunlap @ 2009-10-14 21:59 UTC (permalink / raw)
To: akpm, netdev; +Cc: linux-kernel, David Choi
In-Reply-To: <200910140436.n9E4aF9G001644@imap1.linux-foundation.org>
From: Randy Dunlap <randy.dunlap@oracle.com>
ks8851_mll uses mii interfaces so it needs to select MII.
ks8851_mll.c:(.text+0xf95ac): undefined reference to `generic_mii_ioctl'
ks8851_mll.c:(.text+0xf96a0): undefined reference to `mii_ethtool_gset'
ks8851_mll.c:(.text+0xf96fa): undefined reference to `mii_ethtool_sset'
ks8851_mll.c:(.text+0xf9754): undefined reference to `mii_link_ok'
ks8851_mll.c:(.text+0xf97ae): undefined reference to `mii_nway_restart'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: David Choi <david.choi@micrel.com>
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- mmotm-2009-1013-2113.orig/drivers/net/Kconfig
+++ mmotm-2009-1013-2113/drivers/net/Kconfig
@@ -1741,6 +1741,7 @@ config KS8851
config KS8851_MLL
tristate "Micrel KS8851 MLL"
depends on HAS_IOMEM
+ select MII
help
This platform driver is for Micrel KS8851 Address/data bus
multiplexed network chip.
^ permalink raw reply
* Re: [PATCH] net: Fix OF platform drivers coldplug/hotplug when compiled as modules
From: David Miller @ 2009-10-14 21:54 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, netdev
In-Reply-To: <20091008121512.GA2390@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 8 Oct 2009 16:15:12 +0400
> Some OF platform drivers are missing module device tables, so they won't
> load automatically on boot. This patch fixes the issue by adding proper
> MODULE_DEVICE_TABLE() macros to the drivers.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, thanks!
^ permalink raw reply
* Re: PF_RING: Include in main line kernel?
From: David Miller @ 2009-10-14 21:49 UTC (permalink / raw)
To: greearb; +Cc: zbr, deri, shemminger, brad.doctor, netdev
In-Reply-To: <4AD64251.50903@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Wed, 14 Oct 2009 14:27:45 -0700
> Maybe something similar to the attached patch?
This is not something I'm interested in applying.
It makes implementing proprietary complete networking stacks
for Linux way too easy.
Instead I'd rather have a GPL exported function that allows indication
of consumption somehow. That's why we have a special hook for
bonding, so it cannot be abused in proprietary modules.
^ permalink raw reply
* Re: PF_RING: Include in main line kernel?
From: Luca Deri @ 2009-10-14 21:34 UTC (permalink / raw)
To: Ben Greear; +Cc: Evgeniy Polyakov, Stephen Hemminger, Brad Doctor, netdev
In-Reply-To: <4AD64251.50903@candelatech.com>
Ben
the patch implements what I looked for.
Thanks Luca
On Oct 14, 2009, at 11:27 PM, Ben Greear wrote:
> On 10/14/2009 01:36 PM, Evgeniy Polyakov wrote:
>> On Wed, Oct 14, 2009 at 10:17:30PM +0200, Luca Deri (deri@ntop.org)
>> wrote:
>>> The reason why I decided to patch dev.c is because I wanted
>>> PF_RING to
>>> decide whether the packet journey shall continue or not. In other
>>> words with my solution PF_RING applications can decide whether the
>>> received packets will also be delivered to upper layers (and to
>>> other
>>> kernel network components). This configurable 'early packet drop'
>>> allows the overall performance to be significantly increased as
>>> received packets are not supposed to be delivered to upper layers;
>>> this is a typical situations for many monitoring devices.
>>
>> This is a feature many projects implement themself indeed. What about
>> creating special return value from the packet handler which will
>> indicate that packet was already consumed and no further work
>> should be
>> done on it?
>
> Maybe something similar to the attached patch?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
> <patch0.patch>
^ permalink raw reply
* Re: query: bnx2 and tg3 don't check tcp and/or ip header length validity?
From: Michael Chan @ 2009-10-14 21:24 UTC (permalink / raw)
To: William Allen Simpson; +Cc: netdev@vger.kernel.org
In-Reply-To: <4AD638AC.3000901@gmail.com>
On Wed, 2009-10-14 at 13:46 -0700, William Allen Simpson wrote:
> William Allen Simpson wrote:
> > My question is whether it would be OK to add a simple test, and set it to
> > zero in case of bad values?
> >
> Although both are compiled in my build, I've got no way to test them. I'm
> just going to do the easy thing and set to zero for now. Somebody that
> knows the code -- who should have done real error checking -- could actually
> write better error checking and comments about the purpose of cramming the
> length of the TCP option field into a tag....
The option length is needed by the hardware to segment a TSO packet into
proper MTU-sized packets. You'll get malformed packets if the TSO
header is bad. Setting it to zero perhaps can make these bad packets
more deterministic, but I don't know for sure.
>
> - tcp_opt_len = tcp_optlen(skb);
> + tcp_opt_len = tcp_option_len_th(tcp_hdr(skb));
> + if (tcp_opt_len < 0)
> + tcp_opt_len = 0;
>
^ permalink raw reply
* Re: PF_RING: Include in main line kernel?
From: Ben Greear @ 2009-10-14 21:27 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Luca Deri, Stephen Hemminger, Brad Doctor, netdev
In-Reply-To: <20091014203640.GB32317@ioremap.net>
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On 10/14/2009 01:36 PM, Evgeniy Polyakov wrote:
> On Wed, Oct 14, 2009 at 10:17:30PM +0200, Luca Deri (deri@ntop.org) wrote:
>> The reason why I decided to patch dev.c is because I wanted PF_RING to
>> decide whether the packet journey shall continue or not. In other
>> words with my solution PF_RING applications can decide whether the
>> received packets will also be delivered to upper layers (and to other
>> kernel network components). This configurable 'early packet drop'
>> allows the overall performance to be significantly increased as
>> received packets are not supposed to be delivered to upper layers;
>> this is a typical situations for many monitoring devices.
>
> This is a feature many projects implement themself indeed. What about
> creating special return value from the packet handler which will
> indicate that packet was already consumed and no further work should be
> done on it?
Maybe something similar to the attached patch?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
[-- Attachment #2: patch0.patch --]
[-- Type: text/plain, Size: 2636 bytes --]
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 907d118..da78f0a 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -78,6 +78,7 @@ struct wireless_dev;
#define NET_RX_CN_MOD 3 /* Storm on its way! */
#define NET_RX_CN_HIGH 4 /* The storm is here */
#define NET_RX_BAD 5 /* packet dropped due to kernel error */
+#define NET_RX_CONSUMED 6 /* pkt is consumed, stop rx logic here. */
/* NET_XMIT_CN is special. It does not guarantee that this packet is lost. It
* indicates that the device will soon be dropping packets, or already drops
diff --git a/net/core/dev.c b/net/core/dev.c
index 0101178..d5024b9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2105,6 +2105,10 @@ static inline struct sk_buff *handle_bridge(struct sk_buff *skb,
if (*pt_prev) {
*ret = deliver_skb(skb, *pt_prev, orig_dev);
*pt_prev = NULL;
+ if (*ret == NET_RX_CONSUMED) {
+ kfree_skb(skb); /* we made a copy in deliver_skb */
+ return NULL;
+ }
}
return br_handle_frame_hook(port, skb);
@@ -2128,6 +2132,10 @@ static inline struct sk_buff *handle_macvlan(struct sk_buff *skb,
if (*pt_prev) {
*ret = deliver_skb(skb, *pt_prev, orig_dev);
*pt_prev = NULL;
+ if (*ret == NET_RX_CONSUMED) {
+ kfree_skb(skb); /* we made a copy in deliver_skb */
+ return NULL;
+ }
}
return macvlan_handle_frame_hook(skb);
}
@@ -2185,6 +2193,10 @@ static inline struct sk_buff *handle_ing(struct sk_buff *skb,
if (*pt_prev) {
*ret = deliver_skb(skb, *pt_prev, orig_dev);
*pt_prev = NULL;
+ if (*ret == NET_RX_CONSUMED) {
+ kfree_skb(skb); /* we made a copy in deliver_skb */
+ return NULL;
+ }
} else {
/* Huh? Why does turning on AF_PACKET affect this? */
skb->tc_verd = SET_TC_OK2MUNGE(skb->tc_verd);
@@ -2300,8 +2312,13 @@ int netif_receive_skb(struct sk_buff *skb)
list_for_each_entry_rcu(ptype, &ptype_all, list) {
if (ptype->dev == null_or_orig || ptype->dev == skb->dev ||
ptype->dev == orig_dev) {
- if (pt_prev)
+ if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
+ if (ret == NET_RX_CONSUMED) {
+ kfree_skb(skb); /* we made a copy in deliver_skb */
+ goto out;
+ }
+ }
pt_prev = ptype;
}
}
@@ -2336,8 +2353,13 @@ ncls:
if (ptype->type == type &&
(ptype->dev == null_or_orig || ptype->dev == skb->dev ||
ptype->dev == orig_dev)) {
- if (pt_prev)
+ if (pt_prev) {
ret = deliver_skb(skb, pt_prev, orig_dev);
+ if (ret == NET_RX_CONSUMED) {
+ kfree_skb(skb); /* we made a copy in deliver_skb */
+ goto out;
+ }
+ }
pt_prev = ptype;
}
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox