msm: kgsl: Resolve a potential race in the interrupt handler

In the GPU interrupt handler we attempt to clear the ts_cmp_enable
for the active context so that future interrupts are skipped until
someone needs one again. If for some reason the interrupt handler
is delayed then there is a possiblity that the "current" context in
the GPU isn't the one that fired the interrupt. In that case we
could be accidently clearing a ts_cmp_enable for a context that
needs it. Instead of clearing in the interrupt handler clear it
from the GPU so we can be sure we got the right context.

As a bonus pushing this logic to the GPU side lets us get rid of
some extra register reads/writes in the interrupt handlers.

Orig Change-Id: I3cb3d1a3c626d0594e55bff4535990c1402764fa
Orig Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>
Remove 1113 MHz frequency
Minor defconfig tweaks
genlock: Add minor changes
kernel/sys.c: fix stack memory content leak via UNAME26

Calling uname() with the UNAME26 personality set allows a leak of kernel
stack contents.  This fixes it by defensively calculating the length of
copy_to_user() call, making the len argument unsigned, and initializing
the stack buffer to zero (now technically unneeded, but hey, overkill).

CVE-2012-0957

Reported-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
staging: android: lowmemorykiller: Reduce debug_level to 1

Under certain circumstances, such as after the lowmemorykiller
has recently killed an application, the logs can get flooded
with "select to kill" messages.

Change-Id: I7ae1de47c77d929e04b99be3432577d4f5fd1b2d
Signed-off-by: Liam Mark <lmark@codeaurora.org>
android/lowmemorykiller: Check all tasks for death pending

The lowmemorykiller uses the TIF_MEMDIE flag to help ensure it doesn't
kill another task until the memory from the previously killed task has
been returned to the system.

However the lowmemorykiller does not currently look at tasks who do not
have a tasks->mm, but just because a process doesn't have a tasks->mm
does not mean that the task's memory has been fully returned to the
system yet.

In order to prevent the lowmemorykiller from unnecessarily killing
multiple applications in a row the lowmemorykiller has been changed to
ensure that previous killed tasks are no longer in the process list
before attempting to kill another task.

Change-Id: I7d8a8fd39ca5625e6448ed2efebfb621f6e93845
Signed-off-by: Liam Mark <lmark@codeaurora.org>