1. 23 5月, 2008 1 次提交
  2. 21 5月, 2008 1 次提交
  3. 16 4月, 2008 1 次提交
  4. 05 4月, 2008 1 次提交
  5. 26 3月, 2008 2 次提交
  6. 18 3月, 2008 1 次提交
  7. 06 3月, 2008 1 次提交
  8. 24 2月, 2008 1 次提交
  9. 18 2月, 2008 1 次提交
  10. 01 2月, 2008 1 次提交
    • C
      [VLAN]: set_rx_mode support for unicast address list · e83a2ea8
      Chris Leech 提交于
      Reuse the existing logic for multicast list synchronization for the
      unicast address list. The core of dev_mc_sync/unsync are split out as
      __dev_addr_sync/unsync and moved from dev_mcast.c to dev.c.  These are
      then used to implement dev_unicast_sync/unsync as well.
      
      I'm working on cleaning up Intel's FCoE stack, which generates new MAC
      addresses from the fibre channel device id assigned by the fabric as
      per the current draft specification in T11.  When using such a
      protocol in a VLAN environment it would be nice to not always be
      forced into promiscuous mode, assuming the underlying Ethernet driver
      supports multiple unicast addresses as well.
      Signed-off-by: NChris Leech <christopher.leech@intel.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      e83a2ea8
  11. 29 1月, 2008 9 次提交
  12. 29 11月, 2007 1 次提交
  13. 11 11月, 2007 1 次提交
  14. 11 10月, 2007 3 次提交
  15. 27 8月, 2007 1 次提交
    • E
      [VLAN/BRIDGE]: Fix "skb_pull_rcsum - Fatal exception in interrupt" · e7c243c9
      Evgeniy Polyakov 提交于
      I tried to preserve bridging code as it was before, but logic is quite
      strange - I think we should free skb on error, since it is already
      unshared and thus will just leak.
      
      Herbert Xu states:
      
      > +	if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL)
      > +		goto out;
      
      If this happens it'll be a double-free on skb since we'll
      return NF_DROP which makes the caller free it too.
      
      We could return NF_STOLEN to prevent that but I'm not sure
      whether that's correct netfilter semantics.  Patrick, could
      you please make a call on this?
      
      Patrick McHardy states:
      
      NF_STOLEN should work fine here.
      Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e7c243c9
  16. 01 8月, 2007 1 次提交
    • M
      [NET]: ethtool ops are the only way · 61a44b9c
      Matthew Wilcox 提交于
      During the transition to the ethtool_ops way of doing things, we supported
      calling the device's ->do_ioctl method to allow unconverted drivers to
      continue working.  Those days are long behind us, all in-tree drivers
      use the ethtool_ops way, and so we no longer need to support this.
      
      The bonding driver is the biggest beneficiary of this; it no longer
      needs to call ioctl() as a fallback if ethtool_ops aren't supported.
      
      Also put a proper copyright statement on ethtool.c.
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61a44b9c
  17. 15 7月, 2007 2 次提交
  18. 12 7月, 2007 1 次提交
    • P
      [VLAN]: Fix MAC address handling · 8c979c26
      Patrick McHardy 提交于
      The VLAN MAC address handling is broken in multiple ways. When the address
      differs when setting it, the real device is put in promiscous mode twice,
      but never taken out again. Additionally it doesn't resync when the real
      device's address is changed and needlessly puts it in promiscous mode when
      the vlan device is still down.
      
      Fix by moving address handling to vlan_dev_open/vlan_dev_stop and properly
      deal with address changes in the device notifier. Also switch to
      dev_unicast_add (which needs the exact same handling).
      
      Since the set_mac_address handler is identical to the generic ethernet one
      with these changes, kill it and use ether_setup().
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c979c26
  19. 11 7月, 2007 3 次提交
  20. 26 4月, 2007 4 次提交
  21. 14 4月, 2007 1 次提交
    • J
      [VLAN]: Allow VLAN interface on top of bridge interface · 279e172a
      Jerome Borsboom 提交于
      When a VLAN interface is created on top of a bridge interface and 
      netfilter is enabled to see the bridged packets, the packets can be 
      corrupted when passing through the netfilter code. This is caused by the 
      VLAN driver not setting the 'protocol' and 'nh' members of the sk_buff 
      structure. In general, this is no problem as the VLAN interface is mostly 
      connected to a physical ethernet interface which does not use the 
      'protocol' and 'nh' members. For a bridge interface, however, these 
      members do matter.
      Signed-off-by: NJerome Borsboom <j.borsboom@erasmusmc.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      279e172a
  22. 11 2月, 2007 1 次提交
  23. 11 10月, 2006 1 次提交