Merge tag 'MMI-KXB21.14-L1.40' into cm-11.0

Falcon push for KitKat 4.4.4
falcon: Add fully generated defconfig

* Motorola package version: MM-KXB21.14-L1.32

Change-Id: I8a8bb312b80b32afe43ed5dc08842c4e332303cd
falcon: Enable XZ compression

Change-Id: I222f208bacc3621d43ac035a7dc1eae5d73275e1
falcon: Disable modules whitelist

Change-Id: I8c975d2fe7e58ea54245f395d08d3d965b8fcabe
falcon: Update defconfig

Change-Id: I1c0a81f44c52a0266ccff2fdeaba0ccb306f5c4e
msm: smd: fix in-tree compilation

In-tree compilation for arch/arm/mach-msm/smd_init_dt.c was hitting this
error:

arch/arm/mach-msm/smd_init_dt.c:24:25: fatal error: smd_private.h: No such
file or directory
 #include <smd_private.h>

This was due to using <> instead of "" style include.

Change-Id: I462d259410377244cd551db910df9e15521544ed
Signed-off-by: Kumar Gala <galak@codeaurora.org>
ASoC: msm: fix in-tree compilation for RTAC

In-tree compilation for sound/soc/msm/qdsp6v2/rtac.c was hitting this
error:

sound/soc/msm/qdsp6v2/rtac.c:27:21: fatal error: q6voice.h: No such file
or directory
 #include <q6voice.h>

This was due to using <> instead of "" style include.

Change-Id: Ie96cc91bd29e44c55b9fb0cbc36e25786d6f8823
Signed-off-by: Kumar Gala <galak@codeaurora.org>
msm: Fix compiling kernel in place

A number of files incorrectly used system include notation <> for header
files that are local.  Fix thoses cases to now be #include "FILE.h" instead
of #include <FILE.h>

Change-Id: I1467268b10b33b6fd29bc36b2312378a0b1dde32
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Fix uninitialized div_s64 for gcc 4.9

I know we aren't even close to using gcc 4.9, so this might not get merged
for a while, but here it is for when the time comes. :)  4.9 is even more finicky.

Missing include.

Change-Id: Ia1a0b675f37623735bc1c041fbdd0be61cdaa427
ALSA: Export audio effects header

Export audio_effects.h for userland to use

Change-Id: Ib4b040a87bcf89542d8c9dfb363fcd5f9a1bfc76
drivers: platform: msm: qpnp-vibrator: Add sysfs interface for intensity

To control the Haptic intensity using sysfs interface.

Signed-off-by: SpaceKiller <alexisalbo.1@gmail.com>

Fix vibrator sysfs

Change-Id: Ic33ab91b35039bb3ca9f42949dfffdb34b6276b1
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>
Git-commit: 550c7910f0e2fd4f130fec2f17541f3614fdfaf9
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
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
Git-commit: a2ec8e3dcdc6c93f574a0e22039b791cc5e14fa6
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
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
Git-commit: b50939f89dae691f8da9e0fd22e0eae0db1c0ae4
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
net/l2tp: don't fall back on UDP [get|set]sockopt

The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.

As David Miller points out:

  "If we wanted this to work, it'd have to look up the tunnel and then
   use tunnel->sk, but I wonder how useful that would be"

Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.

Change-Id: I7d00fb0c595cdd65f9724d710f93ca5362019e43
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: James Chapman <jchapman@katalix.com>
Acked-by: David Miller <davem@davemloft.net>
Cc: Phil Turnbull <phil.turnbull@oracle.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Divya Sharma <c_shard@codeaurora.org>
msm: kgsl: Enable protected mode for A3XX

Enable protected register mode for A3XX with these commits from
msm-3.10:

msm: kgsl: Enable protected register mode for A3XX
msm: kgsl: Print the register that causes a protected mode error
msm: kgsl: Unprotect the VBIF performance counters

Change-Id: Ic0dedbad950ffbd063fd861d9440bb5dce8d5fb1
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
msm: kgsl: Protect SMMU registers from being written by the GPU

Put the SMMU register range in protected mode to shield them from
IB1/IB2 writes from userspace.

CRs-Fixed: 599971
Change-Id: Ic0dedbad8c03fc1c54ff73221231e2440d3c34dd
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
peregrine: Add peregrine defconfig

Change-Id: I250b63484b4612e333b0b9fc03910e635830a9a6
falcon: Disable swap

* This is not useful

Change-Id: Idce85b26e847f20f91f7999f684cb6d72a029139
msm8926_mmi: Update defconfig

Change-Id: I28200c6a3b5ef52a3ef9b97743ff824ebc163db9