1. 28 7月, 2015 4 次提交
  2. 27 7月, 2015 30 次提交
  3. 25 7月, 2015 6 次提交
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 48516438
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS fixes for net
      
      The following patchset contains ten Netfilter/IPVS fixes, they are:
      
      1) Address refcount leak when creating an expectation from the ctnetlink
         interface.
      
      2) Fix bug splat in the IDLETIMER target related to sysfs, from Dmitry
         Torokhov.
      
      3) Resolve panic for unreachable route in IPVS with locally generated
         traffic in the output path, from Alex Gartrell.
      
      4) Fix wrong source address in rare cases for tunneled traffic in IPVS,
         from Julian Anastasov.
      
      5) Fix crash if scheduler is changed via ipvsadm -E, again from Julian.
      
      6) Make sure skb->sk is unset for forwarded traffic through IPVS, again from
         Alex Gartrell.
      
      7) Fix crash with IPVS sync protocol v0 and FTP, from Julian.
      
      8) Reset sender cpu for forwarded traffic in IPVS, also from Julian.
      
      9) Allocate template conntracks through kmalloc() to resolve netns dependency
         problems with the conntrack kmem_cache.
      
      10) Fix zones with expectations that clash using the same tuple, from Joe
          Stringer.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48516438
    • K
      cgroup: net_cls: fix false-positive "suspicious RCU usage" · cc9f4daa
      Konstantin Khlebnikov 提交于
      In dev_queue_xmit() net_cls protected with rcu-bh.
      
      [  270.730026] ===============================
      [  270.730029] [ INFO: suspicious RCU usage. ]
      [  270.730033] 4.2.0-rc3+ #2 Not tainted
      [  270.730036] -------------------------------
      [  270.730040] include/linux/cgroup.h:353 suspicious rcu_dereference_check() usage!
      [  270.730041] other info that might help us debug this:
      [  270.730043] rcu_scheduler_active = 1, debug_locks = 1
      [  270.730045] 2 locks held by dhclient/748:
      [  270.730046]  #0:  (rcu_read_lock_bh){......}, at: [<ffffffff81682b70>] __dev_queue_xmit+0x50/0x960
      [  270.730085]  #1:  (&qdisc_tx_lock){+.....}, at: [<ffffffff81682d60>] __dev_queue_xmit+0x240/0x960
      [  270.730090] stack backtrace:
      [  270.730096] CPU: 0 PID: 748 Comm: dhclient Not tainted 4.2.0-rc3+ #2
      [  270.730098] Hardware name: OpenStack Foundation OpenStack Nova, BIOS Bochs 01/01/2011
      [  270.730100]  0000000000000001 ffff8800bafeba58 ffffffff817ad487 0000000000000007
      [  270.730103]  ffff880232a0a780 ffff8800bafeba88 ffffffff810ca4f2 ffff88022fb23e00
      [  270.730105]  ffff880232a0a780 ffff8800bafebb68 ffff8800bafebb68 ffff8800bafebaa8
      [  270.730108] Call Trace:
      [  270.730121]  [<ffffffff817ad487>] dump_stack+0x4c/0x65
      [  270.730148]  [<ffffffff810ca4f2>] lockdep_rcu_suspicious+0xe2/0x120
      [  270.730153]  [<ffffffff816a62d2>] task_cls_state+0x92/0xa0
      [  270.730158]  [<ffffffffa00b534f>] cls_cgroup_classify+0x4f/0x120 [cls_cgroup]
      [  270.730164]  [<ffffffff816aac74>] tc_classify_compat+0x74/0xc0
      [  270.730166]  [<ffffffff816ab573>] tc_classify+0x33/0x90
      [  270.730170]  [<ffffffffa00bcb0a>] htb_enqueue+0xaa/0x4a0 [sch_htb]
      [  270.730172]  [<ffffffff81682e26>] __dev_queue_xmit+0x306/0x960
      [  270.730174]  [<ffffffff81682b70>] ? __dev_queue_xmit+0x50/0x960
      [  270.730176]  [<ffffffff816834a3>] dev_queue_xmit_sk+0x13/0x20
      [  270.730185]  [<ffffffff81787770>] dev_queue_xmit+0x10/0x20
      [  270.730187]  [<ffffffff8178b91c>] packet_snd.isra.62+0x54c/0x760
      [  270.730190]  [<ffffffff8178be25>] packet_sendmsg+0x2f5/0x3f0
      [  270.730203]  [<ffffffff81665245>] ? sock_def_readable+0x5/0x190
      [  270.730210]  [<ffffffff817b64bb>] ? _raw_spin_unlock+0x2b/0x40
      [  270.730216]  [<ffffffff8173bcbc>] ? unix_dgram_sendmsg+0x5cc/0x640
      [  270.730219]  [<ffffffff8165f367>] sock_sendmsg+0x47/0x50
      [  270.730221]  [<ffffffff8165f42f>] sock_write_iter+0x7f/0xd0
      [  270.730232]  [<ffffffff811fd4c7>] __vfs_write+0xa7/0xf0
      [  270.730234]  [<ffffffff811fe5b8>] vfs_write+0xb8/0x190
      [  270.730236]  [<ffffffff811fe8c2>] SyS_write+0x52/0xb0
      [  270.730239]  [<ffffffff817b6bae>] entry_SYSCALL_64_fastpath+0x12/0x76
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc9f4daa
    • W
      77e62da6
    • W
      sch_plug: purge buffered packets during reset · fe6bea7f
      WANG Cong 提交于
      Otherwise the skbuff related structures are not correctly
      refcount'ed.
      
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe6bea7f
    • D
      Merge branch 'fib_select_default-fixes' · c42a6e8b
      David S. Miller 提交于
      Julian Anastasov says:
      
      ====================
      ipv4: fib_select_default changes
      
      This patchset contains 2 changes for the alternative routes,
      one to add tb_id/fa_slen check needed after the recent
      fib_trie optimizations for fib aliases and the second
      change attempts to support alternative routes with TOS
      requirement.
      
      	Sorry that I don't have access to the original
      report from Hagen Paul Pfeifer. I hope he will see this
      change.
      
      	The second change adds fa_default field to the
      fib aliases (which can be many) and if the feature to
      filter the alternative routes by TOS is not worth it,
      this second patch can be scrapped.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c42a6e8b
    • J
      ipv4: consider TOS in fib_select_default · 2392debc
      Julian Anastasov 提交于
      fib_select_default considers alternative routes only when
      res->fi is for the first alias in res->fa_head. In the
      common case this can happen only when the initial lookup
      matches the first alias with highest TOS value. This
      prevents the alternative routes to require specific TOS.
      
      This patch solves the problem as follows:
      
      - routes that require specific TOS should be returned by
      fib_select_default only when TOS matches, as already done
      in fib_table_lookup. This rule implies that depending on the
      TOS we can have many different lists of alternative gateways
      and we have to keep the last used gateway (fa_default) in first
      alias for the TOS instead of using single tb_default value.
      
      - as the aliases are ordered by many keys (TOS desc,
      fib_priority asc), we restrict the possible results to
      routes with matching TOS and lowest metric (fib_priority)
      and routes that match any TOS, again with lowest metric.
      
      For example, packet with TOS 8 can not use gw3 (not lowest
      metric), gw4 (different TOS) and gw6 (not lowest metric),
      all other gateways can be used:
      
      tos 8 via gw1 metric 2 <--- res->fa_head and res->fi
      tos 8 via gw2 metric 2
      tos 8 via gw3 metric 3
      tos 4 via gw4
      tos 0 via gw5
      tos 0 via gw6 metric 1
      Reported-by: NHagen Paul Pfeifer <hagen@jauu.net>
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2392debc