1. 20 4月, 2013 4 次提交
  2. 25 3月, 2013 1 次提交
  3. 19 2月, 2013 1 次提交
  4. 14 2月, 2013 1 次提交
  5. 12 2月, 2013 1 次提交
    • N
      netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock · 2cde6acd
      Neil Horman 提交于
      __netpoll_rcu_free is used to free netpoll structures when the rtnl_lock is
      already held.  The mechanism is used to asynchronously call __netpoll_cleanup
      outside of the holding of the rtnl_lock, so as to avoid deadlock.
      Unfortunately, __netpoll_cleanup modifies pointers (dev->np), which means the
      rtnl_lock must be held while calling it.  Further, it cannot be held, because
      rcu callbacks may be issued in softirq contexts, which cannot sleep.
      
      Fix this by converting the rcu callback to a work queue that is guaranteed to
      get scheduled in process context, so that we can hold the rtnl properly while
      calling __netpoll_cleanup
      
      Tested successfully by myself.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Cong Wang <amwang@redhat.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cde6acd
  6. 11 2月, 2013 1 次提交
  7. 30 1月, 2013 1 次提交
  8. 07 1月, 2013 1 次提交
  9. 05 1月, 2013 2 次提交
  10. 01 12月, 2012 1 次提交
    • Y
      8021q: fix vlan device to inherit the unicast filtering capability flag · 6e22ce2c
      Yi Zou 提交于
      This bug is observed on running FCoE over a VLAN device associated w/
      a real device that has IFF_UNICAST_FLT set since FCoE would add unicast
      address such as FLOGI MAC to the VLAN interface that FCoE is on. Since
      currently, VLAN device is not inheriting the IFF_UNICAST_FLT flag from the
      parent real device even though the real device is capable of doing unicast
      filtering. This forces the VLAN device and its real device go to promiscuous
      mode unnecessarily even the added address is actually being added to the
      available unicast filter table in real device.
      Signed-off-by: NYi Zou <yi.zou@intel.com>
      Cc: devel@open-fcoe.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e22ce2c
  11. 19 11月, 2012 1 次提交
  12. 09 11月, 2012 1 次提交
  13. 02 11月, 2012 1 次提交
  14. 19 10月, 2012 1 次提交
  15. 17 10月, 2012 1 次提交
  16. 09 10月, 2012 1 次提交
    • F
      vlan: don't deliver frames for unknown vlans to protocols · 48cc32d3
      Florian Zumbiehl 提交于
      6a32e4f9 made the vlan code skip marking
      vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if
      there was an rx_handler, as the rx_handler could cause the frame to be received
      on a different (virtual) vlan-capable interface where that vlan might be
      configured.
      
      As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause
      frames for unknown vlans to be delivered to the protocol stack as if they had
      been received untagged.
      
      For example, if an ipv6 router advertisement that's tagged for a locally not
      configured vlan is received on an interface with macvlan interfaces attached,
      macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the
      macvlan interfaces, which caused it to be passed to the protocol stack, leading
      to ipv6 addresses for the announced prefix being configured even though those
      are completely unusable on the underlying interface.
      
      The fix moves marking as PACKET_OTHERHOST after the rx_handler so the
      rx_handler, if there is one, sees the frame unchanged, but afterwards,
      before the frame is delivered to the protocol stack, it gets marked whether
      there is an rx_handler or not.
      Signed-off-by: NFlorian Zumbiehl <florz@florz.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48cc32d3
  17. 03 10月, 2012 1 次提交
  18. 02 9月, 2012 1 次提交
  19. 25 8月, 2012 1 次提交
  20. 15 8月, 2012 4 次提交
  21. 18 7月, 2012 1 次提交
  22. 11 7月, 2012 1 次提交
  23. 11 5月, 2012 1 次提交
  24. 10 5月, 2012 1 次提交
    • J
      8021q: Convert compare_ether_addr to ether_addr_equal · 53a2b3a1
      Joe Perches 提交于
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      Done via cocci script:
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53a2b3a1
  25. 02 4月, 2012 1 次提交
  26. 14 12月, 2011 2 次提交
  27. 09 12月, 2011 5 次提交
  28. 04 12月, 2011 1 次提交