1. 28 Jan, 2016 2 commits
    • Miklos Szeredi's avatar
      ovl: allow zero size xattr · 4c5fbe5f
      Miklos Szeredi authored
      commit 97daf8b9 upstream.
      
      When ovl_copy_xattr() encountered a zero size xattr no more xattrs were
      copied and the function returned success.  This is clearly not the desired
      behavior.
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      4c5fbe5f
    • David Hildenbrand's avatar
      hotplugcpu: Avoid deadlocks by waking active_writer · b3e0811f
      David Hildenbrand authored
      commit 87af9e7f upstream.
      
      Commit b2c4623d ("rcu: More on deadlock between CPU hotplug and expedited
      grace periods") introduced another problem that can easily be reproduced by
      starting/stopping cpus in a loop.
      
      E.g.:
        for i in `seq 5000`; do
            echo 1 > /sys/devices/system/cpu/cpu1/online
            echo 0 > /sys/devices/system/cpu/cpu1/online
        done
      
      Will result in:
        INFO: task /cpu_start_stop:1 blocked for more than 120 seconds.
        Call Trace:
        ([<00000000006a028e>] __schedule+0x406/0x91c)
         [<0000000000130f60>] cpu_hotplug_begin+0xd0/0xd4
         [<0000000000130ff6>] _cpu_up+0x3e/0x1c4
         [<0000000000131232>] cpu_up+0xb6/0xd4
         [<00000000004a5720>] device_online+0x80/0xc0
         [<00000000004a57f0>] online_store+0x90/0xb0
        ...
      
      And a deadlock.
      
      Problem is that if the last ref in put_online_cpus() can't get the
      cpu_hotplug.lock the puts_pending count is incremented, but a sleeping
      active_writer might never be woken up, therefore never exiting the loop in
      cpu_hotplug_begin().
      
      This fix removes puts_pending and turns refcount into an atomic variable. We
      also introduce a wait queue for the active_writer, to avoid possible races and
      use-after-free. There is no need to take the lock in put_online_cpus() anymore.
      
      Can't reproduce it with this fix.
      Signed-off-by: default avatarDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b3e0811f
  2. 26 Jan, 2016 1 commit
  3. 22 Jan, 2016 2 commits
    • Nikolay Aleksandrov's avatar
      net: ipmr: fix static mfc/dev leaks on table destruction · 8a2fe4b0
      Nikolay Aleksandrov authored
      commit 0e615e96 upstream.
      
      When destroying an mrt table the static mfc entries and the static
      devices are kept, which leads to devices that can never be destroyed
      (because of refcnt taken) and leaked memory, for example:
      unreferenced object 0xffff880034c144c0 (size 192):
        comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
        hex dump (first 32 bytes):
          98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
          ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
        backtrace:
          [<ffffffff815c1b9e>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff811ea6e0>] kmem_cache_alloc+0x190/0x300
          [<ffffffff815931cb>] ip_mroute_setsockopt+0x5cb/0x910
          [<ffffffff8153d575>] do_ip_setsockopt.isra.11+0x105/0xff0
          [<ffffffff8153e490>] ip_setsockopt+0x30/0xa0
          [<ffffffff81564e13>] raw_setsockopt+0x33/0x90
          [<ffffffff814d1e14>] sock_common_setsockopt+0x14/0x20
          [<ffffffff814d0b51>] SyS_setsockopt+0x71/0xc0
          [<ffffffff815cdbf6>] entry_SYSCALL_64_fastpath+0x16/0x7a
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Make sure that everything is cleaned on netns destruction.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      8a2fe4b0
    • Kamal Mostafa's avatar
      Linux 3.19.8-ckt13 · 137baa87
      Kamal Mostafa authored
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      137baa87
  4. 20 Jan, 2016 35 commits