commit 9926146b15 upstream.
When testing the "e1000: enhance frame fragment detection" (and e1000e)
patches we found some bugs with reducing the MTU size. The 1024 byte
descriptor used with the 1000 mtu test also (re) introduced the
(originally) reported bug, and causes us to need the e1000_clean_tx_irq
"enhance frame fragment detection" fix.
So what has occured here is that 2.6.32 is only vulnerable for mtu <
1500 due to the jumbo specific routines in both e1000 and e1000e.
So, 2.6.32 needs the 2kB buffer len fix for those smaller MTUs, but
is not vulnerable to the original issue reported. It has been pointed
out that this vulnerability needs to be patched in older kernels that
don't have the e1000 jumbo routine. Without the jumbo routines, we
need the "enhance frame fragment detection" fix the e1000, old
e1000e is only vulnerable for < 1500 mtu, and needs a similar
fix. We split the patches up to provide easy backport paths.
There is only a slight bit of extra code when this fix and the
original "enhance frame fragment detection" fixes are applied, so
please apply both, even though it is a bit of overkill.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 40a14deaf4 upstream.
Originally From: Neil Horman <nhorman@tuxdriver.com>
Modified by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Hey all-
A security discussion was recently given:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html
And a patch that I submitted awhile back was brought up. Apparently some of
their testing revealed that they were able to force a buffer fragment in e1000
in which the trailing fragment was greater than 4 bytes. As a result the
fragment check I introduced failed to detect the fragement and a partial
invalid frame was passed up into the network stack. I've written this patch
to correct it. I'm in the process of testing it now, but it makes good
logical sense to me. Effectively it maintains a per-adapter state variable
which detects a non-EOP frame, and discards it and subsequent non-EOP frames
leading up to _and_ _including_ the next positive-EOP frame (as it is by
definition the last fragment). This should prevent any and all partial frames
from entering the network stack from e1000.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The function e1000_enable_tx_pkt_filtering() was removed in
a previous cleanup patch. this removes the no longer used
prototype.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
this patch fixes a bug that occurs when routing packets and simultaneously
changing the mtu. the rx_buffer_len variable is used during the rx cleanup
and if that changes on the fly without stopping traffic bad things happen
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1) 82544 does not need last_tx_tso workaround, it interferes with the 82544
workaround too
2) 82544 hang workaround was using the address of the page struct instead of
the physical address as its "workaround decider" not sure how that ever worked
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
e1000 was using one particular way to detect link, but with the advent
of some of the newer hardware designs using SERDES connections, tests
for link must completely cover all cases.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
this patch is the first in a series of clean up patches for e1000 to drop
unused code, and update the driver to kernel spec, and then, to update the
driver to have all available bug fixes.
Call it the e1000 weight loss plan.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dev_ioctl() already checks capable(CAP_NET_ADMIN) before calling the
driver's implementation of MDIO ioctls.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Enabling VLAN filters (VFE) when the primary interface is brought up
(per commit 78ed11a) has caused problems for some users who manage
their systems using IPMI over a VLAN. This is because when the driver
enables the VLAN filter, this same filter table is enabled for the
management channel, and the table is initially empty, which means that
the IPMI/VLAN packets are filtered out and not received by the BMC.
This is a problem only on e1000 class adapters, as it is only
on e1000 that the filter table is common to the management and host
streams.
With this change, filtering is only enabled when one or more host VLANs
exist, and is disabled when the last host VLAN is removed. VLAN filtering
is always disabled when the primary interface is in promiscuous mode,
and will be (re)enabled if VLANs exist when the interface exits
promiscuous mode.
Note that this does not completely resolve the issue for those using VLAN
management, because if the host adds a VLAN, then the above problem
occurs when that VLAN is enabled. However, it does mean the there is no
problem for configurations where management is on a VLAN and the host is
not.
A complete solution to this issue would require further driver changes.
The driver would need to discover if (and which) management VLANs are
active before enabling VLAN filtering, so that it could ensure that the
managed VLANs are included in the VLAN filter table. This discovery
requires that the BMC identifies its VLAN in registers accessible
to the driver, and at least on Dell PE2850 systems the BMC does not
identify its VLAN to allow such discovery. Intel is pursuing this issue
with the BMC vendor.
Signed-off-by: Dave Graham <david.graham@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
when testing the jumbo frames with pages patch, the stats would
show rx_missed errors (dropped packets) even when connected to a
link partner with flow control enabled.
this indicates that for this MTU (9000) the flow control
thresholds are not adjusting correctly.
In fact, before this change, the FCRTH (xoff threshold) is 36864
when the fifo size is only 40000, with 9000 byte MTU.
fix it so that we at least have room for one frame after we send
the xoff.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is code extremely similar to what is committed in e1000e
already.
e1000 will no longer request 32kB slab buffers to support jumbo
frames on PCI/PCI-X adapters. This will significantly reduce the
likelyhood of order:3 allocation failures.
This new code adds support for using pages as receive buffers,
and the driver will chain multiple pages together to build a
jumbo frame for OS consumption.
The hardware takes a power of two buffer size and will
dump as much data as it can receive into 1 or more buffers.
The benefits of applying this are
1) stop akpm's dissing :-) of this lame e1000 behavior [1]
2) more efficient memory allocation (half) when using jumbo
frames, which will also allow for much better socket utilization
with jumbos since the socket is charged for the full allocation
of each receive buffer, regardless of how much is used.
3) this was a feature request by a customer
4) copybreak for small packets < 256 bytes still applies
[1] http://lkml.org/lkml/2008/7/10/68http://article.gmane.org/gmane.linux.network/130986
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch allows on-the-fly adjustment of the interrupts per second generated
by e1000 devices 82545/82546 (hardware support of ITR register is a
requirement)
adjust using this command:
ethtool -C eth0 rx-usecs 10
where 10 is 10 microseconds per interrupt interval, so 10 = 100,000 interrupts
per second, and 125 = 8000 interrupts per second.
changes should be immediate.
1,3 are special values and indicate the automatic tuning mode to the driver,
where 1 is 4000-90000 interrupts per second and 3 is 4000-20000 interrupts
per second and is the driver default.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PCI drivers that implement the io_error_detected callback
should return PCI_ERS_RESULT_DISCONNECT if the state
passed in is pci_channel_io_perm_failure. This state is
not checked in many of the network drivers.
The patch fixes the omission in the e1000 driver.
Based on Mike Mason's similar patch for e1000e.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
CC: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
