kernel_samsung_smdk4412/kernel, branch replicant-6.0

perf: protect group_leader from races that cause ctx double-free

2016-12-12T13:14:53+00:00

When moving a group_leader perf event from a software-context
to a hardware-context, there's a race in checking and
updating that context. The existing locking solution
doesn't work; note that it tries to grab a lock inside
the group_leader's context object, which you can only
get at by going through a pointer that should be protected
from these races. To avoid that problem, and to produce
a simple solution, we can just use a lock per group_leader
to protect all checks on the group_leader's context.
The new lock is grabbed and released when no context locks
are held.

RM-290

Bug: 30955111
Bug: 31095224
Change-Id: If37124c100ca6f4aa962559fba3bd5dbbec8e052

BACKPORT: perf: Fix event->ctx locking

2016-12-12T13:14:53+00:00

There have been a few reported issues wrt. the lack of locking around
changing event->ctx. This patch tries to address those.

It avoids the whole rwsem thing; and while it appears to work, please
give it some thought in review.

What I did fail at is sensible runtime checks on the use of
event->ctx, the RCU use makes it very hard.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Paul E. McKenney 
Cc: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/20150123125834.209535886@infradead.org
Signed-off-by: Ingo Molnar 

(cherry picked from commit f63a8daa5812afef4f06c962351687e1ff9ccb2b)
Bug: 30955111
Bug: 31095224

Change-Id: I5bab713034e960fad467637e98e914440de5666d

BACKPORT: perf: Introduce perf_pmu_migrate_context()

2016-12-12T13:14:52+00:00

Originally from Peter Zijlstra. The helper migrates perf events
from one cpu to another cpu.

Conflicts (perf: Fix race in removing an event):
    kernel/events/core.c

Change-Id: I7885fe36c9e2803b10477d556163197085be3d19
Signed-off-by: Zheng Yan 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1339741902-8449-5-git-send-email-zheng.z.yan@intel.com
Signed-off-by: Ingo Molnar

BACKPORT: perf: Allow the PMU driver to choose the CPU on which to install events

2016-12-12T13:14:52+00:00

Allow the pmu->event_init callback to change event->cpu, so the PMU driver
can choose the CPU on which to install events.

Change-Id: I0f8b4310d306f4c87bc961f0359c2bdf65c129b6
Signed-off-by: Zheng Yan 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1339741902-8449-4-git-send-email-zheng.z.yan@intel.com
Signed-off-by: Ingo Molnar

perf: Fix race in swevent hash

2016-11-11T02:26:51+00:00

There's a race on CPU unplug where we free the swevent hash array
while it can still have events on. This will result in a
use-after-free which is BAD.

Simply do not free the hash array on unplug. This leaves the thing
around and no use-after-free takes place.

When the last swevent dies, we do a for_each_possible_cpu() iteration
anyway to clean these up, at which time we'll free it, so no leakage
will occur.

Change-Id: I751faf3215bbdaa6b6358f3a752bdd24126cfa0b
Reported-by: Sasha Levin 
Tested-by: Sasha Levin 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Signed-off-by: Ingo Molnar

smdk4412 : fix build

2016-10-20T19:14:37+00:00

Change-Id: I0e5b9979850042d790cb89996163bdc69a4c7879

net: Fix use after free in the recvmmsg exit path

2016-10-18T13:33:04+00:00

The syzkaller fuzzer hit the following use-after-free:

  Call Trace:
   [] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295
   [] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261
   [<     inline     >] SYSC_recvmmsg net/socket.c:2281
   [] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270
   [] entry_SYSCALL_64_fastpath+0x16/0x7a
  arch/x86/entry/entry_64.S:185

And, as Dmitry rightly assessed, that is because we can drop the
reference and then touch it when the underlying recvmsg calls return
some packets and then hit an error, which will make recvmmsg to set
sock->sk->sk_err, oops, fix it.

Reported-and-Tested-by: Dmitry Vyukov 
Cc: Alexander Potapenko 
Cc: Eric Dumazet 
Cc: Kostya Serebryany 
Cc: Sasha Levin 
Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall")
http://lkml.kernel.org/r/20160122211644.GC2470@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller 

Change-Id: Ie3b6ee89ad3e8cd3a0fe8f50f74aaa4834d0b4ca

mm: add a field to store names for private anonymous memory

2016-08-23T11:55:14+00:00

Userspace processes often have multiple allocators that each do
anonymous mmaps to get memory.  When examining memory usage of
individual processes or systems as a whole, it is useful to be
able to break down the various heaps that were allocated by
each layer and examine their size, RSS, and physical memory
usage.

This patch adds a user pointer to the shared union in
vm_area_struct that points to a null terminated string inside
the user process containing a name for the vma.  vmas that
point to the same address will be merged, but vmas that
point to equivalent strings at different addresses will
not be merged.

Userspace can set the name for a region of memory by calling
prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, start, len, (unsigned long)name);
Setting the name to NULL clears it.

The names of named anonymous vmas are shown in /proc/pid/maps
as [anon:] and in /proc/pid/smaps in a new "Name" field
that is only present for named vmas.  If the userspace pointer
is no longer valid all or part of the name will be replaced
with "".

The idea to store a userspace pointer to reduce the complexity
within mm (at the expense of the complexity of reading
/proc/pid/mem) came from Dave Hansen.  This results in no
runtime overhead in the mm subsystem other than comparing
the anon_name pointers when considering vma merging.  The pointer
is stored in a union with fieds that are only used on file-backed
mappings, so it does not increase memory usage.

Change-Id: I53b093d98dc24f41377824f34e076edced4a6f07

drivers:lmk: Fix double delete issue

2016-06-13T04:47:40+00:00

someone may change a process's oom_score_adj by proc fs, even though the
process has exited. In that case, the task was deleted from the rb tree
already, and the redundant deleting would trigger rb_erase panic finally.

In this patch, we make sure to clear the node after deteting and check
its empty status before rb_erase.

Change-Id: I7628c7d21011099e796b7d366cbc142f96bb8aab
Signed-off-by: Hong-Mei Li 
Reviewed-on: http://gerrit.mot.com/725306
SLTApproved: Slta Waiver 
SME-Granted: SME Approvals Granted
Tested-by: Jira Key 
Reviewed-by: Sheng-Zhe Zhao 
Submit-Approved: Jira Key

staging: android: lowmemorykiller: implement task's adj rbtree

2016-06-13T04:47:39+00:00

Based on the current LMK implementation, LMK has to scan all processes to
select the correct task to kill during low memory.
The basic idea for the optimization is to :
queue all tasks with oom_score_adj priority, and then LMK just selects the
proper task from the queue(rbtree) to kill.

performance improvement:
the current implementation: average time to find a task to kill : 1004us
the optimized implementation: average time to find a task to kill: 43us

Change-Id: I4dbbdd5673314dbbdabb71c3eff0dc229ce4ea91
Signed-off-by: Hong-Mei Li 
Reviewed-on: http://gerrit.pcs.mot.com/548917
SLT-Approved: Slta Waiver 
Tested-by: Jira Key 
Reviewed-by: Yi-Wei Zhao 
Submit-Approved: Jira Key 
Signed-off-by: D. Andrei Măceș 

Conflicts:
	drivers/staging/android/Kconfig
	drivers/staging/android/lowmemorykiller.c
	fs/proc/base.c
	mm/oom_kill.c

Conflicts:
	drivers/staging/android/lowmemorykiller.c
	mm/oom_kill.c

Conflicts:
	mm/oom_kill.c

Conflicts:
	drivers/staging/android/lowmemorykiller.c
	mm/oom_kill.c