1. 19 2月, 2010 1 次提交
  2. 17 2月, 2010 1 次提交
  3. 18 1月, 2010 1 次提交
  4. 02 12月, 2009 1 次提交
  5. 18 11月, 2009 1 次提交
  6. 02 11月, 2009 1 次提交
  7. 29 10月, 2009 1 次提交
  8. 24 10月, 2009 1 次提交
  9. 25 9月, 2009 1 次提交
  10. 01 9月, 2009 1 次提交
  11. 06 7月, 2009 1 次提交
  12. 23 6月, 2009 1 次提交
  13. 03 6月, 2009 1 次提交
  14. 18 5月, 2009 1 次提交
  15. 10 2月, 2009 1 次提交
  16. 26 11月, 2008 1 次提交
  17. 24 11月, 2008 1 次提交
    • A
      net: fix tunnels in netns after ndo_ changes · be77e593
      Alexey Dobriyan 提交于
      dev_net_set() should be the very first thing after alloc_netdev().
      
      "ndo_" changes turned simple assignment (which is OK to do before netns
      assignment) into quite non-trivial operation (which is not OK, init_net was
      used). This leads to incomplete initialisation of tunnel device in netns.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000004
      IP: [<c02efdb5>] ip6_tnl_exit_net+0x37/0x4f
      *pde = 00000000 
      Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
      last sysfs file: /sys/class/net/lo/operstate
      
      Pid: 10, comm: netns Not tainted (2.6.28-rc6 #1) 
      EIP: 0060:[<c02efdb5>] EFLAGS: 00010246 CPU: 0
      EIP is at ip6_tnl_exit_net+0x37/0x4f
      EAX: 00000000 EBX: 00000020 ECX: 00000000 EDX: 00000003
      ESI: c5caef30 EDI: c782bbe8 EBP: c7909f50 ESP: c7909f48
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process netns (pid: 10, ti=c7908000 task=c7905780 task.ti=c7908000)
      Stack:
       c03e75e0 c7390bc8 c7909f60 c0245448 c7390bd8 c7390bf0 c7909fa8 c012577a
       00000000 00000002 00000000 c0125736 c782bbe8 c7909f90 c0308fe3 c782bc04
       c7390bd4 c0245406 c084b718 c04f0770 c03ad785 c782bbe8 c782bc04 c782bc0c
      Call Trace:
       [<c0245448>] ? cleanup_net+0x42/0x82
       [<c012577a>] ? run_workqueue+0xd6/0x1ae
       [<c0125736>] ? run_workqueue+0x92/0x1ae
       [<c0308fe3>] ? schedule+0x275/0x285
       [<c0245406>] ? cleanup_net+0x0/0x82
       [<c0125ae1>] ? worker_thread+0x81/0x8d
       [<c0128344>] ? autoremove_wake_function+0x0/0x33
       [<c0125a60>] ? worker_thread+0x0/0x8d
       [<c012815c>] ? kthread+0x39/0x5e
       [<c0128123>] ? kthread+0x0/0x5e
       [<c0103b9f>] ? kernel_thread_helper+0x7/0x10
      Code: db e8 05 ff ff ff 89 c6 e8 dc 04 f6 ff eb 08 8b 40 04 e8 38 89 f5 ff 8b 44 9e 04 85 c0 75 f0 43 83 fb 20 75 f2 8b 86 84 00 00 00 <8b> 40 04 e8 1c 89 f5 ff e8 98 04 f6 ff 89 f0 e8 f8 63 e6 ff 5b 
      EIP: [<c02efdb5>] ip6_tnl_exit_net+0x37/0x4f SS:ESP 0068:c7909f48
      ---[ end trace 6c2f2328fccd3e0c ]---
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be77e593
  18. 22 11月, 2008 1 次提交
  19. 21 11月, 2008 1 次提交
  20. 21 9月, 2008 1 次提交
  21. 12 6月, 2008 1 次提交
  22. 22 5月, 2008 1 次提交
  23. 16 4月, 2008 7 次提交
  24. 06 3月, 2008 2 次提交
  25. 05 3月, 2008 1 次提交
  26. 27 2月, 2008 1 次提交
    • P
      [INET]: Don't create tunnels with '%' in name. · b37d428b
      Pavel Emelyanov 提交于
      Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can receive a
      pre-defined name for a device from the userspace.  Since these drivers
      call the register_netdevice() (rtnl_lock, is held), which does _not_
      generate the device's name, this name may contain a '%' character.
      
      Not sure how bad is this to have a device with a '%' in its name, but
      all the other places either use the register_netdev(), which call the
      dev_alloc_name(), or explicitly call the dev_alloc_name() before
      registering, i.e. do not allow for such names.
      
      This had to be prior to the commit 34cc7b, but I forgot to number the
      patches and this one got lost, sorry.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b37d428b
  27. 24 2月, 2008 1 次提交
  28. 19 2月, 2008 1 次提交
  29. 29 1月, 2008 4 次提交
  30. 24 10月, 2007 1 次提交