msm: display: only release kickoff when no cleanup pipe

If there is some pipe to clean up, need wait for it be done to
make sure the pipe can be used for the second cycle and recover
mode can be executed.

Change-Id: Ifb3fdb152bc4bbf367b3d272aa0c88b1a0650c19
Signed-off-by: Ken Zhang <kenz@codeaurora.org>
Signed-off-by: Neti Ravi Kumar <ravineti@codeaurora.org>
CRs-Fixed: 659999
msm: display: Add pipe type selection in overlay request

Allow user to specify the type when requesting an overlay pipe.
If field is set the pipe type indication in the flags will be
ignored.
Change-Id: Iee51d24b96c7a2a987dc70a439342e6548dfc8fa
Signed-off-by: Vineet Bajaj <vbajaj@codeaurora.org>
msm: mdss: Clear the previous state of pipe during SOLID_FILL

Clear the previous state of pipe when it is being used in SOLID_FILL
operation to prevent wrong register configuration. For ex: Use case
when DMA pipe was used in BLOCK mode in previous frame, then it is
being used in LINE mode for SOLID_FILL operation in current frame.

CRs-Fixed: 655993
Change-Id: I0ed257276428b96c10a92457a16df4dfdc42c1f8
Signed-off-by: Sushil Chauhan <sushilchauhan@codeaurora.org>
msm: mdss: add support for rotator in mdss_mdp_mixer_get

Currently ctl->mfd is not populated for rotator sessions. If
mdss_mdp_mixer_get is called by rotator session then it will always
fail the NULL check for ctl->mfd. This will flood the logs for every
rotator commit and can lead to un-predictable outcome. Fix this by
properly handling rotator case in mdss_mdp_mixer_get.

Change-Id: Ib1896149302bd60b99028ae26df2393fab30dd6e
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
msm: mdss: fix sync fence deadlock when rotator is used

In the current implementation, whenever rotator play is called, it
forces DMA pipes to be released by calling commit on video mode ctl
paths if they are using DMA pipes. Here assumption was that DMA pipes
will either be used in block mode or line mode, all or none. But this
assumption is not valid any more where we can have a use-case where
DMA0 is used for rotator and DMA1 for video mode ctl path. In this
use-case, current implementation can lead to sync fence deadlock. Fix
this by removing obsolete assumption.

Change-Id: I2d1da9dca5d958257796d617db11d93631c98f27
CRs-Fixed: 656463
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
msm: mdss: modify userspace src format during MSMFB_SET on rotator

The req->src.format field should be changed to the destination
format and propagated to the user so that appropriate buffer size
calculations for the destination buffer can be made. Note, this
only changes the user copy and the driver fetches the source buffer
based on source format.

CRs-fixed: 686496
Change-Id: I590829796c00aeea8e3d9b10578126dd7afe9c82
Signed-off-by: Sree Sesha Aravind Vadrevu <svadrevu@codeaurora.org>
msm: mdss: fix rotator failures when pixel format changes

Current code fails the SMP allocation in the rotator session
when the pixel format during the session changes from YUV to
RGB. Fix these failures by releasing the SMP allocation
if pixel format changes.

Change-Id: Ic051ad4c48be6d4998d392fa74f7b3fb2c131980
Signed-off-by: Ingrid Gallardo <ingridg@codeaurora.org>
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>
Git-commit: 5b3bbe42f5874081123fa3aa4dd85d5e5c806f54
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
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>
net: guard tcp_set_keepalive() to tcp sockets

Its possible to use RAW sockets to get a crash in
tcp_set_keepalive() / sk_reset_timer()

Fix is to make sure socket is a SOCK_STREAM one.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge pull request #1 from intervigilium/cm-11.0

merge Ethan Chan