1. 02 6月, 2011 1 次提交
  2. 27 5月, 2011 1 次提交
  3. 26 5月, 2011 1 次提交
  4. 13 5月, 2011 1 次提交
  5. 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
  6. 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
  7. 18 4月, 2011 2 次提交
  8. 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
  9. 03 4月, 2011 1 次提交
  10. 31 3月, 2011 1 次提交
  11. 19 3月, 2011 1 次提交
  12. 08 3月, 2011 1 次提交
  13. 25 1月, 2011 1 次提交
  14. 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
  15. 17 11月, 2010 2 次提交
  16. 16 11月, 2010 4 次提交
  17. 26 10月, 2010 1 次提交
  18. 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
  19. 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
  20. 01 10月, 2010 1 次提交
  21. 28 9月, 2010 2 次提交
  22. 24 9月, 2010 1 次提交
  23. 21 9月, 2010 1 次提交
  24. 18 9月, 2010 1 次提交
  25. 01 9月, 2010 1 次提交
  26. 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
  27. 23 8月, 2010 1 次提交
  28. 19 8月, 2010 1 次提交
  29. 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
  30. 10 7月, 2010 1 次提交
    • B
      net: Get rid of rtnl_link_stats64 / net_device_stats union · 3cfde79c
      Ben Hutchings 提交于
      In commit be1f3c2c "net: Enable 64-bit
      net device statistics on 32-bit architectures" I redefined struct
      net_device_stats so that it could be used in a union with struct
      rtnl_link_stats64, avoiding the need for explicit copying or
      conversion between the two.  However, this is unsafe because there is
      no locking required and no lock consistently held around calls to
      dev_get_stats() and use of the statistics structure it returns.
      
      In commit 28172739 "net: fix 64 bit
      counters on 32 bit arches" Eric Dumazet dealt with that problem by
      requiring callers of dev_get_stats() to provide storage for the
      result.  This means that the net_device::stats64 field and the padding
      in struct net_device_stats are now redundant, so remove them.
      
      Update the comment on net_device_ops::ndo_get_stats64 to reflect its
      new usage.
      
      Change dev_txq_stats_fold() to use struct rtnl_link_stats64, since
      that is what all its callers are really using and it is no longer
      going to be compatible with struct net_device_stats.
      
      Eric Dumazet suggested the separate function for the structure
      conversion.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3cfde79c
  31. 09 7月, 2010 1 次提交
  32. 08 7月, 2010 1 次提交
    • E
      net: fix 64 bit counters on 32 bit arches · 28172739
      Eric Dumazet 提交于
      There is a small possibility that a reader gets incorrect values on 32
      bit arches. SNMP applications could catch incorrect counters when a
      32bit high part is changed by another stats consumer/provider.
      
      One way to solve this is to add a rtnl_link_stats64 param to all
      ndo_get_stats64() methods, and also add such a parameter to
      dev_get_stats().
      
      Rule is that we are not allowed to use dev->stats64 as a temporary
      storage for 64bit stats, but a caller provided area (usually on stack)
      
      Old drivers (only providing get_stats() method) need no changes.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28172739