1. 11 8月, 2016 1 次提交
  2. 17 2月, 2016 1 次提交
  3. 08 10月, 2015 1 次提交
  4. 18 9月, 2015 1 次提交
  5. 02 6月, 2015 1 次提交
  6. 28 5月, 2015 2 次提交
  7. 07 4月, 2015 1 次提交
  8. 03 4月, 2015 1 次提交
  9. 01 4月, 2015 4 次提交
  10. 20 1月, 2015 1 次提交
  11. 24 11月, 2014 2 次提交
    • L
      ip_tunnel: the lack of vti_link_ops' dellink() cause kernel panic · 20ea60ca
      lucien 提交于
      Now the vti_link_ops do not point the .dellink, for fb tunnel device
      (ip_vti0), the net_device will be removed as the default .dellink is
      unregister_netdevice_queue,but the tunnel still in the tunnel list,
      then if we add a new vti tunnel, in ip_tunnel_find():
      
              hlist_for_each_entry_rcu(t, head, hash_node) {
                      if (local == t->parms.iph.saddr &&
                          remote == t->parms.iph.daddr &&
                          link == t->parms.link &&
      ==>                 type == t->dev->type &&
                          ip_tunnel_key_match(&t->parms, flags, key))
                              break;
              }
      
      the panic will happen, cause dev of ip_tunnel *t is null:
      [ 3835.072977] IP: [<ffffffffa04103fd>] ip_tunnel_find+0x9d/0xc0 [ip_tunnel]
      [ 3835.073008] PGD b2c21067 PUD b7277067 PMD 0
      [ 3835.073008] Oops: 0000 [#1] SMP
      .....
      [ 3835.073008] Stack:
      [ 3835.073008]  ffff8800b72d77f0 ffffffffa0411924 ffff8800bb956000 ffff8800b72d78e0
      [ 3835.073008]  ffff8800b72d78a0 0000000000000000 ffffffffa040d100 ffff8800b72d7858
      [ 3835.073008]  ffffffffa040b2e3 0000000000000000 0000000000000000 0000000000000000
      [ 3835.073008] Call Trace:
      [ 3835.073008]  [<ffffffffa0411924>] ip_tunnel_newlink+0x64/0x160 [ip_tunnel]
      [ 3835.073008]  [<ffffffffa040b2e3>] vti_newlink+0x43/0x70 [ip_vti]
      [ 3835.073008]  [<ffffffff8150d4da>] rtnl_newlink+0x4fa/0x5f0
      [ 3835.073008]  [<ffffffff812f68bb>] ? nla_strlcpy+0x5b/0x70
      [ 3835.073008]  [<ffffffff81508fb0>] ? rtnl_link_ops_get+0x40/0x60
      [ 3835.073008]  [<ffffffff8150d11f>] ? rtnl_newlink+0x13f/0x5f0
      [ 3835.073008]  [<ffffffff81509cf4>] rtnetlink_rcv_msg+0xa4/0x270
      [ 3835.073008]  [<ffffffff8126adf5>] ? sock_has_perm+0x75/0x90
      [ 3835.073008]  [<ffffffff81509c50>] ? rtnetlink_rcv+0x30/0x30
      [ 3835.073008]  [<ffffffff81529e39>] netlink_rcv_skb+0xa9/0xc0
      [ 3835.073008]  [<ffffffff81509c48>] rtnetlink_rcv+0x28/0x30
      ....
      
      modprobe ip_vti
      ip link del ip_vti0 type vti
      ip link add ip_vti0 type vti
      rmmod ip_vti
      
      do that one or more times, kernel will panic.
      
      fix it by assigning ip_tunnel_dellink to vti_link_ops' dellink, in
      which we skip the unregister of fb tunnel device. do the same on ip6_vti.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NCong Wang <cwang@twopensource.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20ea60ca
    • I
      ipv6: coding style improvements (remove assignment in if statements) · e5d08d71
      Ian Morris 提交于
      This change has no functional impact and simply addresses some coding
      style issues detected by checkpatch. Specifically this change
      adjusts "if" statements which also include the assignment of a
      variable.
      
      No changes to the resultant object files result as determined by objdiff.
      Signed-off-by: NIan Morris <ipm@chirality.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5d08d71
  12. 20 11月, 2014 1 次提交
  13. 07 11月, 2014 1 次提交
  14. 04 11月, 2014 1 次提交
  15. 08 10月, 2014 1 次提交
    • E
      net: better IFF_XMIT_DST_RELEASE support · 02875878
      Eric Dumazet 提交于
      Testing xmit_more support with netperf and connected UDP sockets,
      I found strange dst refcount false sharing.
      
      Current handling of IFF_XMIT_DST_RELEASE is not optimal.
      
      Dropping dst in validate_xmit_skb() is certainly too late in case
      packet was queued by cpu X but dequeued by cpu Y
      
      The logical point to take care of drop/force is in __dev_queue_xmit()
      before even taking qdisc lock.
      
      As Julian Anastasov pointed out, need for skb_dst() might come from some
      packet schedulers or classifiers.
      
      This patch adds new helper to cleanly express needs of various drivers
      or qdiscs/classifiers.
      
      Drivers that need skb_dst() in their ndo_start_xmit() should call
      following helper in their setup instead of the prior :
      
      	dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
      ->
      	netif_keep_dst(dev);
      
      Instead of using a single bit, we use two bits, one being
      eventually rebuilt in bonding/team drivers.
      
      The other one, is permanent and blocks IFF_XMIT_DST_RELEASE being
      rebuilt in bonding/team. Eventually, we could add something
      smarter later.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02875878
  16. 29 9月, 2014 1 次提交
  17. 16 7月, 2014 1 次提交
    • T
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen 提交于
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      
      Coccinelle patch:
      
      @@
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      @@
      
      (
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      |
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      |
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      )
      
      v9: move comments here from the wrong commit
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c835a677
  18. 26 6月, 2014 1 次提交
    • M
      vti6: Simplify error handling in module init and exit · e59d82fd
      Mathias Krause 提交于
      The error handling in the module init and exit functions can be
      shortened to safe us some code.
      
      1/ Remove the code duplications in the init function, jump straight to
      the existing cleanup code by adding some labels. Also give the error
      message some more value by telling the reason why loading the module has
      failed.
      
      2/ Remove the error handling in the exit function as the only legitimate
      reason xfrm6_protocol_deregister() might fail is inet6_del_protocol()
      returning -1. That, in turn, means some other protocol handler had been
      registered for this very protocol in the meantime. But that essentially
      means we haven't been handling that protocol any more, anyway. What it
      definitely means not is that we "can't deregister protocol". Therefore
      just get rid of that bogus warning. It's plain wrong.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      e59d82fd
  19. 16 5月, 2014 1 次提交
  20. 12 5月, 2014 2 次提交
  21. 14 3月, 2014 6 次提交
  22. 15 2月, 2014 1 次提交
  23. 08 1月, 2014 1 次提交
    • L
      ipv6: pcpu_tstats.syncp should be initialised in ip6_vti.c · 657e5d19
      Li RongQing 提交于
      initialise pcpu_tstats.syncp to kill the calltrace
      [   11.973950] Call Trace:
      [   11.973950]  [<819bbaff>] dump_stack+0x48/0x60
      [   11.973950]  [<819bbaff>] dump_stack+0x48/0x60
      [   11.973950]  [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
      [   11.973950]  [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
      [   11.973950]  [<81079fa7>] lock_acquire+0x77/0xa0
      [   11.973950]  [<81079fa7>] lock_acquire+0x77/0xa0
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
      [   11.973950]  [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<817ca7ab>] ? dev_get_stats+0xcb/0x130
      [   11.973950]  [<811cf8c1>] ? __nla_reserve+0x21/0xd0
      [   11.973950]  [<811cf8c1>] ? __nla_reserve+0x21/0xd0
      [   11.973950]  [<817ca7ab>] dev_get_stats+0xcb/0x130
      [   11.973950]  [<817ca7ab>] dev_get_stats+0xcb/0x130
      [   11.973950]  [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
      [   11.973950]  [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
      [   11.973950]  [<810352e0>] ? kvm_clock_read+0x20/0x30
      [   11.973950]  [<810352e0>] ? kvm_clock_read+0x20/0x30
      [   11.973950]  [<81008e38>] ? sched_clock+0x8/0x10
      [   11.973950]  [<81008e38>] ? sched_clock+0x8/0x10
      [   11.973950]  [<8106ba45>] ? sched_clock_local+0x25/0x170
      [   11.973950]  [<8106ba45>] ? sched_clock_local+0x25/0x170
      [   11.973950]  [<810da6bd>] ? __kmalloc+0x3d/0x90
      [   11.973950]  [<810da6bd>] ? __kmalloc+0x3d/0x90
      [   11.973950]  [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
      [   11.973950]  [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
      [   11.973950]  [<810da81a>] ? slob_alloc_node+0x2a/0x60
      [   11.973950]  [<810da81a>] ? slob_alloc_node+0x2a/0x60
      [   11.973950]  [<817b919a>] ? __alloc_skb+0x6a/0x2b0
      [   11.973950]  [<817b919a>] ? __alloc_skb+0x6a/0x2b0
      [   11.973950]  [<817d8795>] rtmsg_ifinfo+0x65/0xe0
      [   11.973950]  [<817d8795>] rtmsg_ifinfo+0x65/0xe0
      [   11.973950]  [<817cbd31>] register_netdevice+0x531/0x5a0
      [   11.973950]  [<817cbd31>] register_netdevice+0x531/0x5a0
      [   11.973950]  [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
      [   11.973950]  [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
      [   11.973950]  [<817cbdb6>] register_netdev+0x16/0x30
      [   11.973950]  [<817cbdb6>] register_netdev+0x16/0x30
      [   11.973950]  [<81f574a6>] vti6_init_net+0x1c4/0x1d4
      [   11.973950]  [<81f574a6>] vti6_init_net+0x1c4/0x1d4
      [   11.973950]  [<81f573af>] ? vti6_init_net+0xcd/0x1d4
      [   11.973950]  [<81f573af>] ? vti6_init_net+0xcd/0x1d4
      [   11.973950]  [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
      [   11.973950]  [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
      [   11.973950]  [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
      [   11.973950]  [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
      [   11.973950]  [<817c18d1>] register_pernet_device+0x21/0x60
      [   11.973950]  [<817c18d1>] register_pernet_device+0x21/0x60
      [   11.973950]  [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
      [   11.973950]  [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
      [   11.973950]  [<81f574c7>] vti6_tunnel_init+0x11/0x68
      [   11.973950]  [<81f574c7>] vti6_tunnel_init+0x11/0x68
      [   11.973950]  [<81f572a1>] ? mip6_init+0x73/0xb4
      [   11.973950]  [<81f572a1>] ? mip6_init+0x73/0xb4
      [   11.973950]  [<81f0cba4>] do_one_initcall+0xbb/0x15b
      [   11.973950]  [<81f0cba4>] do_one_initcall+0xbb/0x15b
      [   11.973950]  [<811a00d8>] ? sha_transform+0x528/0x1150
      [   11.973950]  [<811a00d8>] ? sha_transform+0x528/0x1150
      [   11.973950]  [<81f0c544>] ? repair_env_string+0x12/0x51
      [   11.973950]  [<81f0c544>] ? repair_env_string+0x12/0x51
      [   11.973950]  [<8105c30d>] ? parse_args+0x2ad/0x440
      [   11.973950]  [<8105c30d>] ? parse_args+0x2ad/0x440
      [   11.973950]  [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
      [   11.973950]  [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
      [   11.973950]  [<81f0cd27>] kernel_init_freeable+0xe3/0x182
      [   11.973950]  [<81f0cd27>] kernel_init_freeable+0xe3/0x182
      [   11.973950]  [<81f0c532>] ? do_early_param+0x7a/0x7a
      [   11.973950]  [<81f0c532>] ? do_early_param+0x7a/0x7a
      [   11.973950]  [<819b5b1b>] kernel_init+0xb/0x100
      [   11.973950]  [<819b5b1b>] kernel_init+0xb/0x100
      [   11.973950]  [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
      [   11.973950]  [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
      [   11.973950]  [<819b5b10>] ? rest_init+0xc0/0xc0
      [   11.973950]  [<819b5b10>] ? rest_init+0xc0/0xc0
      
      Before 469bdcef ("ipv6: fix the use of pcpu_tstats in ip6_vti.c"),
      the pcpu_tstats.syncp is not used to pretect the 64bit elements of
      pcpu_tstats, so not appear this calltrace.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      657e5d19
  24. 05 1月, 2014 1 次提交
  25. 03 1月, 2014 1 次提交
  26. 10 10月, 2013 1 次提交