1. 24 7月, 2013 1 次提交
  2. 29 5月, 2013 1 次提交
  3. 20 4月, 2013 3 次提交
  4. 25 3月, 2013 1 次提交
  5. 11 2月, 2013 1 次提交
  6. 30 1月, 2013 1 次提交
  7. 05 1月, 2013 1 次提交
  8. 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
  9. 19 11月, 2012 1 次提交
  10. 02 11月, 2012 1 次提交
  11. 19 10月, 2012 1 次提交
  12. 11 7月, 2012 1 次提交
  13. 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
  14. 09 12月, 2011 3 次提交
  15. 02 8月, 2011 1 次提交
  16. 22 7月, 2011 1 次提交
  17. 17 6月, 2011 1 次提交
  18. 03 6月, 2011 1 次提交
  19. 27 5月, 2011 1 次提交
  20. 11 5月, 2011 1 次提交
    • E
      vlan: fix GVRP at dismantle time · 55aee10d
      Eric Dumazet 提交于
      ip link add link eth2 eth2.103 type vlan id 103 gvrp on loose_binding on
      ip link set eth2.103 up
      rmmod tg3    # driver providing eth2
      
       BUG: unable to handle kernel NULL pointer dereference at           (null)
       IP: [<ffffffffa0030c9e>] garp_request_leave+0x3e/0xc0 [garp]
       PGD 11d251067 PUD 11b9e0067 PMD 0
       Oops: 0000 [#1] SMP
       last sysfs file: /sys/devices/virtual/net/eth2.104/ifindex
       CPU 0
       Modules linked in: tg3(-) 8021q garp nfsd lockd auth_rpcgss sunrpc libphy sg [last unloaded: x_tables]
      
       Pid: 11494, comm: rmmod Tainted: G        W   2.6.39-rc6-00261-gfd71257-dirty #580 HP ProLiant BL460c G6
       RIP: 0010:[<ffffffffa0030c9e>]  [<ffffffffa0030c9e>] garp_request_leave+0x3e/0xc0 [garp]
       RSP: 0018:ffff88007a19bae8  EFLAGS: 00010286
       RAX: 0000000000000000 RBX: ffff88011b5e2000 RCX: 0000000000000002
       RDX: 0000000000000000 RSI: 0000000000000175 RDI: ffffffffa0030d5b
       RBP: ffff88007a19bb18 R08: 0000000000000001 R09: ffff88011bd64a00
       R10: ffff88011d34ec00 R11: 0000000000000000 R12: 0000000000000002
       R13: ffff88007a19bc48 R14: ffff88007a19bb88 R15: 0000000000000001
       FS:  0000000000000000(0000) GS:ffff88011fc00000(0063) knlGS:00000000f77d76c0
       CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
       CR2: 0000000000000000 CR3: 000000011a675000 CR4: 00000000000006f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Process rmmod (pid: 11494, threadinfo ffff88007a19a000, task ffff8800798595c0)
       Stack:
        ffff88007a19bb36 ffff88011c84b800 ffff88011b5e2000 ffff88007a19bc48
        ffff88007a19bb88 0000000000000006 ffff88007a19bb38 ffffffffa003a5f6
        ffff88007a19bb38 670088007a19bba8 ffff88007a19bb58 ffffffffa00397e7
       Call Trace:
        [<ffffffffa003a5f6>] vlan_gvrp_request_leave+0x46/0x50 [8021q]
        [<ffffffffa00397e7>] vlan_dev_stop+0xb7/0xc0 [8021q]
        [<ffffffff8137e427>] __dev_close_many+0x87/0xe0
        [<ffffffff8137e507>] dev_close_many+0x87/0x110
        [<ffffffff8137e630>] rollback_registered_many+0xa0/0x240
        [<ffffffff8137e7e9>] unregister_netdevice_many+0x19/0x60
        [<ffffffffa00389eb>] vlan_device_event+0x53b/0x550 [8021q]
        [<ffffffff8143f448>] ? ip6mr_device_event+0xa8/0xd0
        [<ffffffff81479d03>] notifier_call_chain+0x53/0x80
        [<ffffffff81062539>] __raw_notifier_call_chain+0x9/0x10
        [<ffffffff81062551>] raw_notifier_call_chain+0x11/0x20
        [<ffffffff8137df82>] call_netdevice_notifiers+0x32/0x60
        [<ffffffff8137e69f>] rollback_registered_many+0x10f/0x240
        [<ffffffff8137e85f>] rollback_registered+0x2f/0x40
        [<ffffffff8137e8c8>] unregister_netdevice_queue+0x58/0x90
        [<ffffffff8137e9eb>] unregister_netdev+0x1b/0x30
        [<ffffffffa005d73f>] tg3_remove_one+0x6f/0x10b [tg3]
      
      We should call vlan_gvrp_request_leave() from unregister_vlan_dev(),
      not from vlan_dev_stop(), because vlan_gvrp_uninit_applicant()
      is called right after unregister_netdevice_queue(). In batch mode,
      unregister_netdevice_queue() doesn’t immediately call vlan_dev_stop().
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55aee10d
  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. 18 4月, 2011 2 次提交
  23. 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
  24. 03 4月, 2011 1 次提交
  25. 25 1月, 2011 1 次提交
  26. 29 11月, 2010 1 次提交
    • J
      8021q: vlan device is lockless do not transfer real_num_{tx|rx}_queues · 19eb5cc5
      John Fastabend 提交于
      Now that the vlan device is lockless and single queue do not
      transfer the real num queues. This is causing a BUG_ON to occur.
      
      kernel BUG at net/8021q/vlan.c:345!
      Call Trace:
      [<ffffffff813fd6e8>] ? fib_rules_event+0x28/0x1b0
      [<ffffffff814ad2b5>] notifier_call_chain+0x55/0x80
      [<ffffffff81089156>] raw_notifier_call_chain+0x16/0x20
      [<ffffffff813e5af7>] call_netdevice_notifiers+0x37/0x70
      [<ffffffff813e6756>] netdev_features_change+0x16/0x20
      [<ffffffffa02995be>] ixgbe_fcoe_enable+0xae/0x100 [ixgbe]
      [<ffffffffa01da06a>] vlan_dev_fcoe_enable+0x2a/0x30 [8021q]
      [<ffffffffa02d08c3>] fcoe_create+0x163/0x630 [fcoe]
      [<ffffffff811244d5>] ? mmap_region+0x255/0x5a0
      [<ffffffff81080ef0>] param_attr_store+0x50/0x80
      [<ffffffff810809b6>] module_attr_store+0x26/0x30
      [<ffffffff811b9db2>] sysfs_write_file+0xf2/0x180
      [<ffffffff8114fc88>] vfs_write+0xc8/0x190
      [<ffffffff81150621>] sys_write+0x51/0x90
      [<ffffffff8100c0b2>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19eb5cc5
  27. 17 11月, 2010 1 次提交
  28. 16 11月, 2010 1 次提交
  29. 26 10月, 2010 1 次提交
  30. 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
  31. 28 9月, 2010 1 次提交
  32. 18 9月, 2010 1 次提交
  33. 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