1. 29 7月, 2015 1 次提交
  2. 28 7月, 2015 4 次提交
  3. 27 7月, 2015 30 次提交
  4. 25 7月, 2015 5 次提交
    • 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