1. 07 6月, 2016 1 次提交
  2. 30 5月, 2016 1 次提交
    • A
      ipv6: hide ip6_encap_hlen/ip6_tnl_encap definitions · 9791d8e7
      Arnd Bergmann 提交于
      A recent cleanup moved MAX_IPTUN_ENCAP_OPS along with some other
      definitions, but it is now invisible when CONFIG_INET is
      not defined, but still referenced from ip6_tunnel.h:
      
      In file included from net/xfrm/xfrm_input.c:17:0:
      include/net/ip6_tunnel.h:67:17: error: 'MAX_IPTUN_ENCAP_OPS' undeclared here (not in a function)
         ip6tun_encaps[MAX_IPTUN_ENCAP_OPS];
                       ^~~~~~~~~~~~~~~~~~~
      
      This hides the ip6_encap_hlen and ip6_tnl_encap functions inside
      of CONFIG_INET so we don't run into the the problem.
      
      Alternatively we could move the macro out of the #ifdef again to
      restore the previous behavior
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 55c2bc14 ("net: Cleanup encap items in ip_tunnels.h")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9791d8e7
  3. 25 5月, 2016 2 次提交
    • E
      netfilter: nf_queue: Make the queue_handler pernet · dc3ee32e
      Eric W. Biederman 提交于
      Florian Weber reported:
      > Under full load (unshare() in loop -> OOM conditions) we can
      > get kernel panic:
      >
      > BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      > IP: [<ffffffff81476c85>] nfqnl_nf_hook_drop+0x35/0x70
      > [..]
      > task: ffff88012dfa3840 ti: ffff88012dffc000 task.ti: ffff88012dffc000
      > RIP: 0010:[<ffffffff81476c85>]  [<ffffffff81476c85>] nfqnl_nf_hook_drop+0x35/0x70
      > RSP: 0000:ffff88012dfffd80  EFLAGS: 00010206
      > RAX: 0000000000000008 RBX: ffffffff81add0c0 RCX: ffff88013fd80000
      > [..]
      > Call Trace:
      >  [<ffffffff81474d98>] nf_queue_nf_hook_drop+0x18/0x20
      >  [<ffffffff814738eb>] nf_unregister_net_hook+0xdb/0x150
      >  [<ffffffff8147398f>] netfilter_net_exit+0x2f/0x60
      >  [<ffffffff8141b088>] ops_exit_list.isra.4+0x38/0x60
      >  [<ffffffff8141b652>] setup_net+0xc2/0x120
      >  [<ffffffff8141bd09>] copy_net_ns+0x79/0x120
      >  [<ffffffff8106965b>] create_new_namespaces+0x11b/0x1e0
      >  [<ffffffff810698a7>] unshare_nsproxy_namespaces+0x57/0xa0
      >  [<ffffffff8104baa2>] SyS_unshare+0x1b2/0x340
      >  [<ffffffff81608276>] entry_SYSCALL_64_fastpath+0x1e/0xa8
      > Code: 65 00 48 89 e5 41 56 41 55 41 54 53 83 e8 01 48 8b 97 70 12 00 00 48 98 49 89 f4 4c 8b 74 c2 18 4d 8d 6e 08 49 81 c6 88 00 00 00 <49> 8b 5d 00 48 85 db 74 1a 48 89 df 4c 89 e2 48 c7 c6 90 68 47
      >
      
      The simple fix for this requires a new pernet variable for struct
      nf_queue that indicates when it is safe to use the dynamically
      allocated nf_queue state.
      
      As we need a variable anyway make nf_register_queue_handler and
      nf_unregister_queue_handler pernet.  This allows the existing logic of
      when it is safe to use the state from the nfnetlink_queue module to be
      reused with no changes except for making it per net.
      
      The syncrhonize_rcu from nf_unregister_queue_handler is moved to a new
      function nfnl_queue_net_exit_batch so that the worst case of having a
      syncrhonize_rcu in the pernet exit path is not experienced in batch
      mode.
      Reported-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      dc3ee32e
    • E
      net_sched: avoid too many hrtimer_start() calls · a9efad8b
      Eric Dumazet 提交于
      I found a serious performance bug in packet schedulers using hrtimers.
      
      sch_htb and sch_fq are definitely impacted by this problem.
      
      We constantly rearm high resolution timers if some packets are throttled
      in one (or more) class, and other packets are flying through qdisc on
      another (non throttled) class.
      
      hrtimer_start() does not have the mod_timer() trick of doing nothing if
      expires value does not change :
      
      	if (timer_pending(timer) &&
                  timer->expires == expires)
                      return 1;
      
      This issue is particularly visible when multiple cpus can queue/dequeue
      packets on the same qdisc, as hrtimer code has to lock a remote base.
      
      I used following fix :
      
      1) Change htb to use qdisc_watchdog_schedule_ns() instead of open-coding
      it.
      
      2) Cache watchdog prior expiration. hrtimer might provide this, but I
      prefer to not rely on some hrtimer internal.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a9efad8b
  4. 21 5月, 2016 7 次提交
  5. 18 5月, 2016 1 次提交
  6. 17 5月, 2016 5 次提交
  7. 13 5月, 2016 1 次提交
  8. 12 5月, 2016 10 次提交
  9. 11 5月, 2016 1 次提交
  10. 10 5月, 2016 1 次提交
  11. 09 5月, 2016 3 次提交
  12. 07 5月, 2016 1 次提交
  13. 06 5月, 2016 1 次提交
  14. 05 5月, 2016 5 次提交