1. 20 4月, 2013 4 次提交
  2. 14 2月, 2013 1 次提交
  3. 30 1月, 2013 1 次提交
  4. 05 1月, 2013 1 次提交
  5. 17 10月, 2012 1 次提交
  6. 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
  7. 03 10月, 2012 1 次提交
  8. 25 8月, 2012 1 次提交
  9. 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
  10. 14 12月, 2011 1 次提交
  11. 09 12月, 2011 4 次提交
  12. 04 12月, 2011 1 次提交
  13. 01 11月, 2011 1 次提交
  14. 30 10月, 2011 1 次提交
    • E
      vlan: allow nested vlan_do_receive() · 6a32e4f9
      Eric Dumazet 提交于
      commit 2425717b (net: allow vlan traffic to be received under bond)
      broke ARP processing on vlan on top of bonding.
      
             +-------+
      eth0 --| bond0 |---bond0.103
      eth1 --|       |
             +-------+
      
      52870.115435: skb_gro_reset_offset <-napi_gro_receive
      52870.115435: dev_gro_receive <-napi_gro_receive
      52870.115435: napi_skb_finish <-napi_gro_receive
      52870.115435: netif_receive_skb <-napi_skb_finish
      52870.115435: get_rps_cpu <-netif_receive_skb
      52870.115435: __netif_receive_skb <-netif_receive_skb
      52870.115436: vlan_do_receive <-__netif_receive_skb
      52870.115436: bond_handle_frame <-__netif_receive_skb
      52870.115436: vlan_do_receive <-__netif_receive_skb
      52870.115436: arp_rcv <-__netif_receive_skb
      52870.115436: kfree_skb <-arp_rcv
      
      Packet is dropped in arp_rcv() because its pkt_type was set to
      PACKET_OTHERHOST in the first vlan_do_receive() call, since no eth0.103
      exists.
      
      We really need to change pkt_type only if no more rx_handler is about to
      be called for the packet.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a32e4f9
  15. 19 8月, 2011 1 次提交
  16. 22 7月, 2011 3 次提交
  17. 12 6月, 2011 1 次提交
    • J
      vlan: Fix the ingress VLAN_FLAG_REORDER_HDR check · 0b5c9db1
      Jiri Pirko 提交于
      Testing of VLAN_FLAG_REORDER_HDR does not belong in vlan_untag
      but rather in vlan_do_receive.  Otherwise the vlan header
      will not be properly put on the packet in the case of
      vlan header accelleration.
      
      As we remove the check from vlan_check_reorder_header
      rename it vlan_reorder_header to keep the naming clean.
      
      Fix up the skb->pkt_type early so we don't look at the packet
      after adding the vlan tag, which guarantees we don't goof
      and look at the wrong field.
      
      Use a simple if statement instead of a complicated switch
      statement to decided that we need to increment rx_stats
      for a multicast packet.
      
      Hopefully at somepoint we will just declare the case where
      VLAN_FLAG_REORDER_HDR is cleared as unsupported and remove
      the code.  Until then this keeps it working correctly.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Acked-by: NChangli Gao <xiaosuo@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b5c9db1
  18. 13 4月, 2011 1 次提交
    • J
      net: vlan: make non-hw-accel rx path similar to hw-accel · bcc6d479
      Jiri Pirko 提交于
      Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
      enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
      vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
      
      For non-rx-vlan-hw-accel however, tagged skb goes thru whole
      __netif_receive_skb, it's untagged in ptype_base hander and reinjected
      
      This incosistency is fixed by this patch. Vlan untagging happens early in
      __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
      see the skb like it was untagged by hw.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      
      v1->v2:
      	remove "inline" from vlan_core.c functions
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bcc6d479
  19. 17 11月, 2010 1 次提交
  20. 21 10月, 2010 1 次提交
    • J
      vlan: Centralize handling of hardware acceleration. · 3701e513
      Jesse Gross 提交于
      Currently each driver that is capable of vlan hardware acceleration
      must be aware of the vlan groups that are configured and then pass
      the stripped tag to a specialized receive function.  This is
      
      different from other types of hardware offload in that it places a
      significant amount of knowledge in the driver itself rather keeping
      it in the networking core.
      
      This makes vlan offloading function more similarly to other forms
      of offloading (such as checksum offloading or TSO) by doing the
      following:
      * On receive, stripped vlans are passed directly to the network
      core, without attempting to check for vlan groups or reconstructing
      the header if no group
      * vlans are made less special by folding the logic into the main
      receive routines
      * On transmit, the device layer will add the vlan header in software
      if the hardware doesn't support it, instead of spreading that logic
      out in upper layers, such as bonding.
      
      There are a number of advantages to this:
      * Fixes all bugs with drivers incorrectly dropping vlan headers at once.
      * Avoids having to disable VLAN acceleration when in promiscuous mode
      (good for bridging since it always puts devices in promiscuous mode).
      * Keeps VLAN tag separate until given to ultimate consumer, which
      avoids needing to do header reconstruction as in tg3 unless absolutely
      necessary.
      * Consolidates common code in core networking.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3701e513
  21. 06 10月, 2010 1 次提交
    • E
      net: add a core netdev->rx_dropped counter · caf586e5
      Eric Dumazet 提交于
      In various situations, a device provides a packet to our stack and we
      drop it before it enters protocol stack :
      - softnet backlog full (accounted in /proc/net/softnet_stat)
      - bad vlan tag (not accounted)
      - unknown/unregistered protocol (not accounted)
      
      We can handle a per-device counter of such dropped frames at core level,
      and automatically adds it to the device provided stats (rx_dropped), so
      that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)
      
      This is a generalization of commit 8990f468 (net: rx_dropped
      accounting), thus reverting it.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      caf586e5
  22. 01 10月, 2010 1 次提交
  23. 24 9月, 2010 1 次提交
  24. 01 9月, 2010 1 次提交
  25. 27 8月, 2010 1 次提交
    • E
      gro: __napi_gro_receive() optimizations · 40d0802b
      Eric Dumazet 提交于
      compare_ether_header() can have a special implementation on 64 bit
      arches if CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is defined.
      
      __napi_gro_receive() and vlan_gro_common() can avoid a conditional
      branch to perform device match.
      
      On x86_64, __napi_gro_receive() has now 38 instructions instead of 53
      
      As gcc-4.4.3 still choose to not inline it, add inline keyword to this
      performance critical function.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40d0802b
  26. 23 8月, 2010 1 次提交
  27. 19 7月, 2010 1 次提交
    • P
      vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet) · ad1afb00
      Pedro Garcia 提交于
      - Without the 8021q module loaded in the kernel, all 802.1p packets 
      (VLAN 0 but QoS tagging) are silently discarded (as expected, as 
      the protocol is not loaded).
       
      - Without this patch in 8021q module, these packets are forwarded to 
      the module, but they are discarded also if VLAN 0 is not configured,
      which should not be the default behaviour, as VLAN 0 is not really
      a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
      impossible to communicate with mixed 802.1p and non 802.1p devices on
      the same network due to arp table issues.
      
      - Changed logic to skip vlan specific code in vlan_skb_recv if VLAN 
      is 0 and we have not defined a VLAN with ID 0, but we accept the 
      packet with the encapsulated proto and pass it later to netif_rx.
      
      - In the vlan device event handler, added some logic to add VLAN 0 
      to HW filter in devices that support it (this prevented any traffic
      in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
      and probably also with other HW filtered cards, so we fix it here).
      
      - In the vlan unregister logic, prevent the elimination of VLAN 0 
      in devices with HW filter.
      
      - The default behaviour is to ignore the VLAN 0 tagging and accept
      the packet as if it was not tagged, but we can still define a 
      VLAN 0 if desired (so it is backwards compatible).
      Signed-off-by: NPedro Garcia <pedro.netdev@dondevamos.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad1afb00
  28. 29 6月, 2010 1 次提交
  29. 11 6月, 2010 1 次提交
    • J
      net: deliver skbs on inactive slaves to exact matches · 597a264b
      John Fastabend 提交于
      Currently, the accelerated receive path for VLAN's will
      drop packets if the real device is an inactive slave and
      is not one of the special pkts tested for in
      skb_bond_should_drop().  This behavior is different then
      the non-accelerated path and for pkts over a bonded vlan.
      
      For example,
      
      vlanx -> bond0 -> ethx
      
      will be dropped in the vlan path and not delivered to any
      packet handlers at all.  However,
      
      bond0 -> vlanx -> ethx
      
      and
      
      bond0 -> ethx
      
      will be delivered to handlers that match the exact dev,
      because the VLAN path checks the real_dev which is not a
      slave and netif_recv_skb() doesn't drop frames but only
      delivers them to exact matches.
      
      This patch adds a sk_buff flag which is used for tagging
      skbs that would previously been dropped and allows the
      skb to continue to skb_netif_recv().  Here we add
      logic to check for the deliver_no_wcard flag and if it
      is set only deliver to handlers that match exactly.  This
      makes both paths above consistent and gives pkt handlers
      a way to identify skbs that come from inactive slaves.
      Without this patch in some configurations skbs will be
      delivered to handlers with exact matches and in others
      be dropped out right in the vlan path.
      
      I have tested the following 4 configurations in failover modes
      and load balancing modes.
      
      # bond0 -> ethx
      
      # vlanx -> bond0 -> ethx
      
      # bond0 -> vlanx -> ethx
      
      # bond0 -> ethx
                  |
        vlanx -> --
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      597a264b
  30. 18 5月, 2010 1 次提交
  31. 19 3月, 2010 1 次提交
  32. 04 1月, 2010 1 次提交
    • A
      bonding: allow arp_ip_targets on separate vlans to use arp validation · 1f3c8804
      Andy Gospodarek 提交于
      This allows a bond device to specify an arp_ip_target as a host that is
      not on the same vlan as the base bond device and still use arp
      validation.  A configuration like this, now works:
      
      BONDING_OPTS="mode=active-backup arp_interval=1000 arp_ip_target=10.0.100.1 arp_validate=3"
      
      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
          inet 127.0.0.1/8 scope host lo
          inet6 ::1/128 scope host
             valid_lft forever preferred_lft forever
      2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
          link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
      3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
          link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
      8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
          link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
          inet6 fe80::213:21ff:febe:33e9/64 scope link
             valid_lft forever preferred_lft forever
      9: bond0.100@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
          link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
          inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
          inet6 fe80::213:21ff:febe:33e9/64 scope link
             valid_lft forever preferred_lft forever
      
      Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
      
      Bonding Mode: fault-tolerance (active-backup)
      Primary Slave: None
      Currently Active Slave: eth1
      MII Status: up
      MII Polling Interval (ms): 0
      Up Delay (ms): 0
      Down Delay (ms): 0
      ARP Polling Interval (ms): 1000
      ARP IP target/s (n.n.n.n form): 10.0.100.1
      
      Slave Interface: eth1
      MII Status: up
      Link Failure Count: 1
      Permanent HW addr: 00:40:05:30:ff:30
      
      Slave Interface: eth0
      MII Status: up
      Link Failure Count: 0
      Permanent HW addr: 00:13:21:be:33:e9
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f3c8804