1. 03 9月, 2010 1 次提交
  2. 26 8月, 2010 1 次提交
  3. 09 8月, 2010 1 次提交
    • J
      e100/e1000*/igb*/ixgb*: Add missing read memory barrier · 2d0bb1c1
      Jeff Kirsher 提交于
      Based on patches from Sonny Rao and Milton Miller...
      
      Combined the patches to fix up clean_tx_irq and clean_rx_irq.
      
      The PowerPC architecture does not require loads to independent bytes
      to be ordered without adding an explicit barrier.
      
      In ixgbe_clean_rx_irq we load the status bit then load the packet data.
      With packet split disabled if these loads go out of order we get a
      stale packet, but we will notice the bad sequence numbers and drop it.
      
      The problem occurs with packet split enabled where the TCP/IP header
      and data are in different descriptors. If the reads go out of order
      we may have data that doesn't match the TCP/IP header. Since we use
      hardware checksumming this bad data is never verified and it makes it
      all the way to the application.
      
      This bug was found during stress testing and adding this barrier has
      been shown to fix it.  The bug can manifest as a data integrity issue
      (bad payload data) or as a BUG in skb_pull().
      
      This was a nasty bug to hunt down, if people agree with the fix I think
      it's a candidate for stable.
      
      Previously Submitted to e1000-devel only for ixgbe
      
      http://marc.info/?l=e1000-devel&m=126593062701537&w=3
      
      We've now seen this problem hit with other device drivers (e1000e mostly)
      So I'm resubmitting with fixes for other Intel Device Drivers with
      similar issues.
      
      CC: Milton Miller <miltonm@bga.com>
      CC: Anton Blanchard <anton@samba.org>
      CC: Sonny Rao <sonnyrao@us.ibm.com>
      CC: stable <stable@kernel.org>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d0bb1c1
  4. 27 7月, 2010 1 次提交
  5. 14 6月, 2010 1 次提交
  6. 14 5月, 2010 3 次提交
  7. 06 5月, 2010 1 次提交
  8. 28 4月, 2010 2 次提交
  9. 15 4月, 2010 1 次提交
  10. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  11. 27 3月, 2010 1 次提交
  12. 23 2月, 2010 3 次提交
  13. 04 2月, 2010 2 次提交
  14. 26 1月, 2010 1 次提交
  15. 23 1月, 2010 1 次提交
    • J
      e1000/e1000e: don't use small hardware rx buffers · 9926146b
      Jesse Brandeburg 提交于
      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: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9926146b
  16. 21 1月, 2010 2 次提交
  17. 08 1月, 2010 1 次提交
  18. 04 12月, 2009 1 次提交
  19. 03 12月, 2009 1 次提交
  20. 14 10月, 2009 1 次提交
  21. 08 10月, 2009 1 次提交
  22. 27 9月, 2009 10 次提交
  23. 04 9月, 2009 1 次提交
  24. 02 9月, 2009 1 次提交
    • G
      e1000: Fix for e1000 kills IPMI on a tagged vlan. · fd38d7a0
      Graham, David 提交于
      Enabling VLAN filters (VFE) when the primary interface is brought up
      (per commit 78ed11a5) 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: NDave Graham <david.graham@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Tested-by: NKrzysztof Piotr Oledzki <ole@ans.pl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd38d7a0