1. 14 Jul, 2008 5 commits
  2. 09 Jul, 2008 1 commit
  3. 08 Jul, 2008 6 commits
  4. 05 Jul, 2008 2 commits
  5. 23 May, 2008 1 commit
  6. 20 May, 2008 1 commit
  7. 16 Apr, 2008 1 commit
  8. 04 Apr, 2008 1 commit
  9. 26 Mar, 2008 1 commit
  10. 25 Mar, 2008 1 commit
  11. 17 Mar, 2008 1 commit
  12. 05 Mar, 2008 1 commit
  13. 23 Feb, 2008 1 commit
  14. 18 Feb, 2008 1 commit
  15. 31 Jan, 2008 1 commit
    • Chris Leech's avatar
      [VLAN]: set_rx_mode support for unicast address list · e83a2ea8
      Chris Leech authored
      
      
      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: default avatarChris Leech <christopher.leech@intel.com>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      e83a2ea8
  16. 28 Jan, 2008 9 commits
  17. 29 Nov, 2007 1 commit
  18. 10 Nov, 2007 1 commit
  19. 10 Oct, 2007 3 commits
  20. 26 Aug, 2007 1 commit
    • Evgeniy Polyakov's avatar
      [VLAN/BRIDGE]: Fix "skb_pull_rcsum - Fatal exception in interrupt" · e7c243c9
      Evgeniy Polyakov authored
      
      
      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: default avatarEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7c243c9