1. 29 Jul, 2015 1 commit
  2. 27 Jul, 2015 27 commits
  3. 26 Jul, 2015 7 commits
  4. 25 Jul, 2015 5 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 48516438
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      48516438
    • Konstantin Khlebnikov's avatar
      cgroup: net_cls: fix false-positive "suspicious RCU usage" · cc9f4daa
      Konstantin Khlebnikov authored
      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: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc9f4daa
    • WANG Cong's avatar
      77e62da6
    • WANG Cong's avatar
      sch_plug: purge buffered packets during reset · fe6bea7f
      WANG Cong authored
      Otherwise the skbuff related structures are not correctly
      refcount'ed.
      
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe6bea7f
    • David S. Miller's avatar
      Merge branch 'fib_select_default-fixes' · c42a6e8b
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      c42a6e8b