1. 08 11月, 2013 1 次提交
  2. 19 7月, 2013 1 次提交
    • E
      vlan: mask vlan prio bits · d4b812de
      Eric Dumazet 提交于
      In commit 48cc32d3
      ("vlan: don't deliver frames for unknown vlans to protocols")
      Florian made sure we set pkt_type to PACKET_OTHERHOST
      if the vlan id is set and we could find a vlan device for this
      particular id.
      
      But we also have a problem if prio bits are set.
      
      Steinar reported an issue on a router receiving IPv6 frames with a
      vlan tag of 4000 (id 0, prio 2), and tunneled into a sit device,
      because skb->vlan_tci is set.
      
      Forwarded frame is completely corrupted : We can see (8100:4000)
      being inserted in the middle of IPv6 source address :
      
      16:48:00.780413 IP6 2001:16d8:8100:4000:ee1c:0:9d9:bc87 >
      9f94:4d95:2001:67c:29f4::: ICMP6, unknown icmp6 type (0), length 64
             0x0000:  0000 0029 8000 c7c3 7103 0001 a0ae e651
             0x0010:  0000 0000 ccce 0b00 0000 0000 1011 1213
             0x0020:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
             0x0030:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
      
      It seems we are not really ready to properly cope with this right now.
      
      We can probably do better in future kernels :
      vlan_get_ingress_priority() should be a netdev property instead of
      a per vlan_dev one.
      
      For stable kernels, lets clear vlan_tci to fix the bugs.
      Reported-by: NSteinar H. Gunderson <sesse@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4b812de
  3. 20 6月, 2013 1 次提交
  4. 08 6月, 2013 1 次提交
  5. 22 4月, 2013 1 次提交
  6. 20 4月, 2013 5 次提交
  7. 28 3月, 2013 1 次提交
    • S
      net: add ETH_P_802_3_MIN · e5c5d22e
      Simon Horman 提交于
      Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
      an 802.3 frame. Frames with a lower value in the ethernet type field
      are Ethernet II.
      
      Also update all the users of this value that David Miller and
      I could find to use the new constant.
      
      Also correct a bug in util.c. The comparison with ETH_P_802_3_MIN
      should be >= not >.
      
      As suggested by Jesse Gross.
      
      Compile tested only.
      
      Cc: David Miller <davem@davemloft.net>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Bart De Schuymer <bart.de.schuymer@pandora.be>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: linux-bluetooth@vger.kernel.org
      Cc: netfilter-devel@vger.kernel.org
      Cc: bridge@lists.linux-foundation.org
      Cc: linux-wireless@vger.kernel.org
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: linux-media@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: dev@openvswitch.org
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5c5d22e
  8. 24 2月, 2013 1 次提交
    • C
      vlan: adjust vlan_set_encap_proto() for its callers · da8c8724
      Cong Wang 提交于
      There are two places to call vlan_set_encap_proto():
      vlan_untag() and __pop_vlan_tci().
      
      vlan_untag() assumes skb->data points after mac addr, otherwise
      the following code
      
              vhdr = (struct vlan_hdr *) skb->data;
              vlan_tci = ntohs(vhdr->h_vlan_TCI);
              __vlan_hwaccel_put_tag(skb, vlan_tci);
      
              skb_pull_rcsum(skb, VLAN_HLEN);
      
      won't be correct. But __pop_vlan_tci() assumes points _before_
      mac addr.
      
      In vlan_set_encap_proto(), it looks for some magic L2 value
      after mac addr:
      
              rawp = skb->data;
              if (*(unsigned short *) rawp == 0xFFFF)
      	...
      
      Therefore __pop_vlan_tci() is obviously wrong.
      
      A quick fix is avoiding using skb->data in vlan_set_encap_proto(),
      use 'vhdr+1' is always correct in both cases.
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jesse Gross <jesse@nicira.com>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Acked-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da8c8724
  9. 13 10月, 2012 1 次提交
  10. 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
  11. 25 8月, 2012 1 次提交
  12. 20 3月, 2012 1 次提交
  13. 05 3月, 2012 1 次提交
    • P
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker 提交于
      If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
      other BUG variant in a static inline (i.e. not in a #define) then
      that header really should be including <linux/bug.h> and not just
      expecting it to be implicitly present.
      
      We can make this change risk-free, since if the files using these
      headers didn't have exposure to linux/bug.h already, they would have
      been causing compile failures/warnings.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  14. 09 12月, 2011 4 次提交
  15. 04 12月, 2011 1 次提交
  16. 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
  17. 22 7月, 2011 6 次提交
  18. 18 7月, 2011 1 次提交
    • D
      net: vlan, qlcnic: make vlan_find_dev private · 69ecca86
      David Lamparter 提交于
      there is only one user of vlan_find_dev outside of the actual vlan code:
      qlcnic uses it to iterate over some VLANs it knows.
      
      let's just make vlan_find_dev private to the VLAN code and have the
      iteration in qlcnic be a bit more direct. (a few rcu dereferences less
      too)
      Signed-off-by: NDavid Lamparter <equinox@diac24.net>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Amit Kumar Salecha <amit.salecha@qlogic.com>
      Cc: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
      Cc: linux-driver@qlogic.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69ecca86
  19. 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
  20. 26 5月, 2011 1 次提交
  21. 10 5月, 2011 1 次提交
    • E
      vlan: remove one synchronize_net() call · 48752e1b
      Eric Dumazet 提交于
      At VLAN dismantle phase, unregister_vlan_dev() makes one
      synchronize_net() call after vlan_group_set_device(grp, vlan_id, NULL).
      
      This call can be safely removed because we are calling
      unregister_netdevice_queue() to queue device for deletion, and this
      process needs at least one rcu grace period to complete.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Ben Greear <greearb@candelatech.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
      Acked-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48752e1b
  22. 13 4月, 2011 2 次提交
  23. 13 11月, 2010 1 次提交
  24. 22 10月, 2010 1 次提交
  25. 21 10月, 2010 3 次提交
    • 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
    • J
      vlan: Avoid hash table lookup to find group. · 65ac6a5f
      Jesse Gross 提交于
      A struct net_device always maps to zero or one vlan groups and we
      always know the device when we are looking up a group.  We currently
      do a hash table lookup on the device to find the group but it is
      much simpler to just store a pointer.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65ac6a5f
    • J
      vlan: Rename VLAN_GROUP_ARRAY_LEN to VLAN_N_VID. · b738127d
      Jesse Gross 提交于
      VLAN_GROUP_ARRAY_LEN is simply the number of possible vlan VIDs.
      Since vlan groups will soon be more of an implementation detail
      for vlan devices, rename the constant to be descriptive of its
      actual purpose.
      Signed-off-by: NJesse Gross <jesse@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b738127d