1. 11 1月, 2014 2 次提交
  2. 10 1月, 2014 2 次提交
  3. 09 1月, 2014 2 次提交
  4. 08 1月, 2014 3 次提交
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · a04c0e2c
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      The following patchset contains two patches:
      
      * fix the IRC NAT helper which was broken when adding (incomplete) IPv6
        support, from Daniel Borkmann.
      
      * Refine the previous bugtrap that Jesper added to catch problems for the
        usage of the sequence adjustment extension in IPVs in Dec 16th, it may
        spam messages in case of finding a real bug.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a04c0e2c
    • E
      tipc: correctly unlink packets from deferred packet queue · 732256b9
      Erik Hugne 提交于
      When we pull a received packet from a link's 'deferred packets' queue
      for processing, its 'next' pointer is not cleared, and still refers to
      the next packet in that queue, if any. This is incorrect, but caused
      no harm before commit 40ba3cdf ("tipc:
      message reassembly using fragment chain") was introduced. After that
      commit, it may sometimes lead to the following oops:
      
      general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
      Modules linked in: tipc
      CPU: 4 PID: 0 Comm: swapper/4 Tainted: G        W 3.13.0-rc2+ #6
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      task: ffff880017af4880 ti: ffff880017aee000 task.ti: ffff880017aee000
      RIP: 0010:[<ffffffff81710694>]  [<ffffffff81710694>] skb_try_coalesce+0x44/0x3d0
      RSP: 0018:ffff880016603a78  EFLAGS: 00010212
      RAX: 6b6b6b6bd6d6d6d6 RBX: ffff880013106ac0 RCX: ffff880016603ad0
      RDX: ffff880016603ad7 RSI: ffff88001223ed00 RDI: ffff880013106ac0
      RBP: ffff880016603ab8 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000000 R12: ffff88001223ed00
      R13: ffff880016603ad0 R14: 000000000000058c R15: ffff880012297650
      FS:  0000000000000000(0000) GS:ffff880016600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000805b000 CR3: 0000000011f5d000 CR4: 00000000000006e0
      Stack:
       ffff880016603a88 ffffffff810a38ed ffff880016603aa8 ffff88001223ed00
       0000000000000001 ffff880012297648 ffff880016603b68 ffff880012297650
       ffff880016603b08 ffffffffa0006c51 ffff880016603b08 00ffffffa00005fc
      Call Trace:
       <IRQ>
       [<ffffffff810a38ed>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffffa0006c51>] tipc_link_recv_fragment+0xd1/0x1b0 [tipc]
       [<ffffffffa0007214>] tipc_recv_msg+0x4e4/0x920 [tipc]
       [<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
       [<ffffffffa000177c>] tipc_l2_rcv_msg+0xcc/0x250 [tipc]
       [<ffffffffa00016f0>] ? tipc_l2_rcv_msg+0x40/0x250 [tipc]
       [<ffffffff8171e65b>] __netif_receive_skb_core+0x80b/0xd00
       [<ffffffff8171df94>] ? __netif_receive_skb_core+0x144/0xd00
       [<ffffffff8171eb76>] __netif_receive_skb+0x26/0x70
       [<ffffffff8171ed6d>] netif_receive_skb+0x2d/0x200
       [<ffffffff8171fe70>] napi_gro_receive+0xb0/0x130
       [<ffffffff815647c2>] e1000_clean_rx_irq+0x2c2/0x530
       [<ffffffff81565986>] e1000_clean+0x266/0x9c0
       [<ffffffff81985f7b>] ? notifier_call_chain+0x2b/0x160
       [<ffffffff8171f971>] net_rx_action+0x141/0x310
       [<ffffffff81051c1b>] __do_softirq+0xeb/0x480
       [<ffffffff819817bb>] ? _raw_spin_unlock+0x2b/0x40
       [<ffffffff810b8c42>] ? handle_fasteoi_irq+0x72/0x100
       [<ffffffff81052346>] irq_exit+0x96/0xc0
       [<ffffffff8198cbc3>] do_IRQ+0x63/0xe0
       [<ffffffff81981def>] common_interrupt+0x6f/0x6f
       <EOI>
      
      This happens when the last fragment of a message has passed through the
      the receiving link's 'deferred packets' queue, and at least one other
      packet was added to that queue while it was there. After the fragment
      chain with the complete message has been successfully delivered to the
      receiving socket, it is released. Since 'next' pointer of the last
      fragment in the released chain now is non-NULL, we get the crash shown
      above.
      
      We fix this by clearing the 'next' pointer of all received packets,
      including those being pulled from the 'deferred' queue, before they
      undergo any further processing.
      
      Fixes: 40ba3cdf ("tipc: message reassembly using fragment chain")
      Signed-off-by: NErik Hugne <erik.hugne@ericsson.com>
      Reported-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      732256b9
    • 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
  5. 07 1月, 2014 13 次提交
  6. 06 1月, 2014 12 次提交
  7. 05 1月, 2014 6 次提交