1. 09 12月, 2011 1 次提交
  2. 02 8月, 2011 1 次提交
  3. 22 7月, 2011 1 次提交
  4. 17 6月, 2011 1 次提交
  5. 03 6月, 2011 1 次提交
  6. 27 5月, 2011 1 次提交
  7. 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
  8. 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
  9. 18 4月, 2011 2 次提交
  10. 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
  11. 03 4月, 2011 1 次提交
  12. 25 1月, 2011 1 次提交
  13. 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
  14. 17 11月, 2010 1 次提交
  15. 16 11月, 2010 1 次提交
  16. 26 10月, 2010 1 次提交
  17. 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
  18. 28 9月, 2010 1 次提交
  19. 18 9月, 2010 1 次提交
  20. 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
  21. 04 4月, 2010 1 次提交
  22. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  23. 25 3月, 2010 1 次提交
  24. 19 3月, 2010 1 次提交
  25. 18 1月, 2010 1 次提交
  26. 04 12月, 2009 1 次提交
  27. 03 12月, 2009 1 次提交
  28. 02 12月, 2009 1 次提交
  29. 27 11月, 2009 1 次提交
  30. 18 11月, 2009 1 次提交
  31. 17 11月, 2009 1 次提交
  32. 30 10月, 2009 1 次提交
  33. 28 10月, 2009 2 次提交
  34. 03 9月, 2009 1 次提交
  35. 15 8月, 2009 1 次提交
  36. 31 7月, 2009 1 次提交