ARM: dts: msm: add perf-events support for msm8x10, msm8x12

Add the device definitions for the Cortex-A7
PMU on msm8x10.

Change-Id: I0e45c01cec2c92e437cc11cee88777bca271b839
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/perf_debug.c
Perf: Make per-process counters configurable

Add feature to enable/disable per-process tracecounters at run-time.

Change-Id: Id6a4c7a0ecd1f5add85464c6ed260860e15c4e3b
Signed-off-by: Sheetal Sahasrabudhe <sheetals@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/perf_debug.c
msm: perf: Add L2 support for tracecounters

Add L2 counter output to the tracecounters implementation.
This enables collection of L2 PMU counter values upon context switch.
Set up filtering based on number of L2 counters and number of cores.
Read L2 counter values and display them along with L1 counter values.

Change-Id: I8bbbd251ee52c66505d22ccf037c601013a916f0
Signed-off-by: Sheetal Sahasrabudhe <sheetals@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/perf_debug.c
Perf: keep events across hotplug

Keep event list alive across a CPU hotplug so that perf
can resume when the CPU comes back online. Bring a CPU
online when exiting a perf session so it can be cleaned
up properly.

Change-Id: Ie0e4a43f751beb77afdc84e9d52b21780f279d80
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/perf_debug.c
Perf: bring CPU online if needed when disabling irq

When disabling an irq, check that the CPU is online
before trying to run on that CPU. Bring the CPU
online if necessary.

This fixes a problem where a CPU that was not online
when disabling the irq caused the disable and the
free to fail. A subsequent attempt to request the irq
also failed because it had not been freed.

Change-Id: Ib873b5ded83ab843ea4e609f196a31ef0083a213
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/perf_debug.c
bcmdhd: Adjust default hostwake/reset GPIOs to match the galbis

Change-Id: I84c3d71dde9fdea45652b24a65523d9947cdd25d
bluesleep: Don't wait for uart tx queue to flush before entering standby

There's no need to delay sleep for this. msm_hs_serial will do it on
its own, and this reduces the time to enter lpm

Change-Id: Ia13d44148130aaf133ea888807b5ba114936ce78
Add L-01F(G2 JPN-DCM) defconfig
Add LGL22 au isai (G2 JPN-KDDI) defconfig
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

If uaddr == uaddr2, then we have broken the rule of only requeueing
from a non-pi futex to a pi futex with this call. If we attempt this,
then dangling pointers may be left for rt_waiter resulting in an
exploitable condition.

This change brings futex_requeue() into line with
futex_wait_requeue_pi() which performs the same check as per commit
6f7b0a2a5 (futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi())

[ tglx: Compare the resulting keys as well, as uaddrs might be
  	different depending on the mapping ]

Fixes CVE-2014-3153.

Reported-by: Pinkie Pie
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Change-Id: I155eafa98f365408450527e34998893dcdd64801
futex: Validate atomic acquisition in futex_lock_pi_atomic()

We need to protect the atomic acquisition in the kernel against rogue
user space which sets the user space futex to 0, so the kernel side
acquisition succeeds while there is existing state in the kernel
associated to the real owner.

Verify whether the futex has waiters associated with kernel state. If
it has, return -EINVAL. The state is corrupted already, so no point in
cleaning it up. Subsequent calls will fail as well. Not our problem.

[ tglx: Use futex_top_waiter() and explain why we do not need to try
  	restoring the already corrupted user space state. ]

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Change-Id: I155eafa98f365408450527e34998893dcdd64802
futex: Always cleanup owner tid in unlock_pi

If the owner died bit is set at futex_unlock_pi, we currently do not
cleanup the user space futex. So the owner TID of the current owner
(the unlocker) persists. That's observable inconsistant state,
especially when the ownership of the pi state got transferred.

Clean it up unconditionally.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org

Change-Id: I155eafa98f365408450527e34998893dcdd64803
futex: Make lookup_pi_state more robust

The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex. We can get into the kernel
even if the TID value is 0, because either there is a stale waiters
bit or the owner died bit is set or we are called from the requeue_pi
path or from user space just for fun.

The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address. This can lead to state leakage and worse under some
circumstances.

Handle the cases explicit:

     Waiter | pi_state | pi->owner | uTID      | uODIED | ?

[1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
[2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

[3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

[4]  Found  | Found    | NULL      | 0         | 1      | Valid
[5]  Found  | Found    | NULL      | >0        | 1      | Invalid

[6]  Found  | Found    | task      | 0         | 1      | Valid

[7]  Found  | Found    | NULL      | Any       | 0      | Invalid

[8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
[9]  Found  | Found    | task      | 0         | 0      | Invalid
[10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

[1]  Indicates that the kernel can acquire the futex atomically. We
     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

[2]  Valid, if TID does not belong to a kernel thread. If no matching
     thread is found then it indicates that the owner TID has died.

[3]  Invalid. The waiter is queued on a non PI futex

[4]  Valid state after exit_robust_list(), which sets the user space
     value to FUTEX_WAITERS | FUTEX_OWNER_DIED.

[5]  The user space value got manipulated between exit_robust_list()
     and exit_pi_state_list()

[6]  Valid state after exit_pi_state_list() which sets the new owner in
     the pi_state but cannot access the user space value.

[7]  pi_state->owner can only be NULL when the OWNER_DIED bit is set.

[8]  Owner and user space value match

[9]  There is no transient state which sets the user space TID to 0
     except exit_robust_list(), but this is indicated by the
     FUTEX_OWNER_DIED bit. See [4]

[10] There is no transient state which leaves owner and user space
     TID out of sync.

Backport to 3.13
  conflicts: kernel/futex.c

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org

Change-Id: I155eafa98f365408450527e34998893dcdd64804
g2: Enable subsystem vmalloc reclaims