1. 28 4月, 2010 2 次提交
  2. 15 4月, 2010 1 次提交
  3. 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
  4. 27 3月, 2010 1 次提交
  5. 25 3月, 2010 1 次提交
  6. 23 2月, 2010 3 次提交
  7. 04 2月, 2010 2 次提交
  8. 26 1月, 2010 1 次提交
  9. 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
  10. 21 1月, 2010 2 次提交
  11. 08 1月, 2010 1 次提交
  12. 04 12月, 2009 1 次提交
  13. 03 12月, 2009 1 次提交
  14. 19 11月, 2009 1 次提交
  15. 14 10月, 2009 2 次提交
  16. 08 10月, 2009 1 次提交
  17. 27 9月, 2009 13 次提交
  18. 21 9月, 2009 1 次提交
  19. 04 9月, 2009 1 次提交
  20. 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
  21. 01 9月, 2009 1 次提交
  22. 27 8月, 2009 1 次提交