kernel/git/stable/linux-stable.git/drivers/net/e1000, branch linux-2.6.32.y

e1000: add dummy allocator to fix race condition between mtu change and netpoll

2015-09-18T11:51:58+00:00

commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream. There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] put_compound_page+0x7e/0x330 [...] Call Trace: [] put_page+0x55/0x60 [] e1000_clean_rx_ring+0x134/0x200 [] e1000_clean_all_rx_rings+0x45/0x60 [] e1000_down+0x1c0/0x1d0 [] ? deactivate_slab+0x7f0/0x840 [] e1000_change_mtu+0xdc/0x170 [] dev_set_mtu+0xa0/0x140 [] do_setlink+0x218/0xac0 [] ? nla_parse+0xb9/0x120 [] rtnl_newlink+0x6d0/0x890 [] ? kvm_clock_read+0x20/0x40 [] ? sched_clock_cpu+0xa8/0x100 [] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors") Signed-off-by: Sabrina Dubroca Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Ben Hutchings (cherry picked from commit f655adbac3de7ce92b2b0f9ce2d426b55b600e38) [wt: path is drivers/net/e1000/e1000_main.c in 2.6.32] Signed-off-by: Willy Tarreau

e1000: Fix driver to be used on PA RISC C8000 workstations

2011-11-07T20:32:01+00:00

commit e2faeec2de9e2c73958e6ea6065dde1e8cd6f3a2 upstream. The checksum field in the EEPROM on HPPA is really not a checksum but a signature (0x16d6). So allow 0x16d6 as the matching checksum on HPPA systems. This issue is present on longterm/stable kernels, I have verified that this patch is applicable back to at least 2.6.32.y kernels. v2- changed ifdef to use CONFIG_PARISC instead of __hppa__ CC: Guy Martin CC: Rolf Eike Beer CC: Matt Turner Reported-by: Mikulas Patocka Signed-off-by: Jeff Kirsher Acked-by: Jesse Brandeburg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

e1000: fix Tx hangs by disabling 64-bit DMA

2011-05-09T22:55:35+00:00

commit e508be174ad36b0cf9b324cd04978c2b13c21502 upstream. Several users report issues with 32-bit adapters when plugged into PCI slots in machines with >= 4GB ram. In particular AMD systems with HyperTransport to PCI bridges seem to trigger the issue, but it isn't limited to only them. This issue is not easily reproducible here, yet still continues to occur in the field. For e1000 on PCI devices, just disable DMA addresses over the 4GB boundary when in PCI (not PCI-X) mode, to prevent the issue from continuing to pop up. The performance impact for this is negligible. The code was refactored to move the init of the hw struct to its own function. This allows the init to be called very early in probe, which then allows using hw-> members for this fix. A slight refactor to the DMA mask code was done for minor correctness based on the instructions in DMA-API-HOWTO. Signed-off-by: Jesse Brandeburg Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller [bwh: Adjust for 2.6.32] Signed-off-by: Greg Kroah-Hartman

e1000/e1000e: don't use small hardware rx buffers

2010-02-09T12:50:45+00:00

commit 9926146b15fd96d78a4f7c32e7a26d50639369f4 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 Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

e1000: enhance frame fragment detection

2010-02-09T12:50:45+00:00

commit 40a14deaf411592b57cb0720f0e8004293ab9865 upstream. Originally From: Neil Horman Modified by: Jesse Brandeburg 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 Acked-by: Neil Horman Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

e1000: cleanup unused prototype

2009-09-27T03:16:05+00:00

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 Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: fix namespacecheck warnings

2009-09-27T03:16:01+00:00

a couple of functions needed to be removed/declared static Signed-off-by: Jesse Brandeburg Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: drop unused functionality for eeprom write/read

2009-09-27T03:15:58+00:00

eerd and eewr don't exist on pre PCIe devices Signed-off-by: Jesse Brandeburg Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: updated whitespace and comments

2009-09-27T03:15:55+00:00

A large whitespace change to e1000_hw.[ch] in order to update it to kernel coding style (by running lindent). Updated function header comments into kdoc style. Signed-off-by: Jesse Brandeburg Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller

e1000: drop redunant line of code, cleanup

2009-09-27T03:15:52+00:00

adapter was being assigned twice, also clarified variable name and unwrapped line. Signed-off-by: Jesse Brandeburg Signed-off-by: Don Skidmore Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller