enable fast chage by default
adjustment
ARM: cacheflush: add new iovec-based cache flushing system call

The cacheflush system call flushes a contiguous range, specified by a
pair of addresses. This means that user applications wishing to flush
discrete ranges must issue multiple system calls, since attempting to
flush past a vma results in range truncation.

This patch introduces a new private system call for ARM, cacheflush_iov,
which processes a range of addresses described in an iovec structure.

Signed-off-by: Will Deacon <will.deacon at arm.com>
OMAP4: EMIF: Added timings for 466MHz elpida lpddr2 memory

OMAP4470 support 466MHz DDR2 memory. This patch add timings from
datasheet for EDB8164B3PF.

Change-Id: Ief7520719a2d7ec3dc9c93a3ecbfcef7cf64507c
Signed-off-by: Vitaly Chernooky <vitaly.chernooky@ti.com>
OMAP4470: Memory timings fix for LPDDR2 466 MHz

Fixed memory timings for LPDDR2 466MHz according to
hardware recommendations.

Change-Id: I07e821c8fafc1b559b61a443083fc9c1acddc87a
Signed-off-by: Mykola Oleksiienko <x0174904@ti.com>
OMAP4470 LPDDR interface configuration update for 466MHz

Some instability with OMAP4470 when running the DDR at 466MHz is
discovered. This instability is resolved with updated LPDDR settings:

- DLL delay should be set to 461ps:
  DDR_PHY_CTRL_1_SHDW[11:4] = 0x37

- Read latency should be set to 0xB:
  DDR_PHY_CTRL_1_SHDW[3:0] = 0xB

- Slew Rate should be set to “FASTEST” and Impedance Control to “Drv12”:
  CONTROL_LPDDR2IOx_2[LPDDR2IO1_GR10_SR] = 0
  CONTROL_LPDDR2IOx_2[LPDDR2IO1_GR10_I] = 7
  where x=[1-2]

Change-Id: Ifa47a7ccae437225db5838039e528c04250a911d
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
ram timing optimize
optimize 466 timings
add back some ion ram
Revert "adjust a set of values"

This reverts commit 32f9d522e07496bbad44e352ce767c315f9e8bb4.
Revert "Staging: Logger from Linux 3.9 (kylon)"

This reverts commit 0b27f212fe55ab7a64608ec6b01cac6f24a3049f.
Revert "Reduce logger RAM"

This reverts commit cb7a989e024f7b88bb38e1e7d8dd99b8279ff1ae.
Reduce logger RAM

Conflicts:
	drivers/staging/android/logger.c
mm: vmscan: check page order in isolating lru pages

Before attempting to take all pages in the order aligned region, check for
page order is added for minor optimization, since the pfn-based isolation
could be bypassed if the newly isolated page is no less than that region.

v1->v2 changes
1, the reason to add the check is described in change log,
2, the check is corrected,
3, comment for the check is corrected.

Thanks for all comments recieved.

Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Hillf Danton <dhillf@gmail.com>
mm: vmscan: recompute page status when putting back

If unlikely the given page is isolated from lru list again, its status is
recomputed before putting back to lru list, since the comment says page's
status can change while we move it among lru.

Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Hillf Danton <dhillf@gmail.com>
mm: simplify find_vma_prev

From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

commit 297c5eee37 (mm: make the vma list be doubly linked) added
vm_prev member into vm_area_struct. Therefore we can simplify
find_vma_prev() by using it. Also, this change help to improve
page fault performance because it has strong locality of reference.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
futex: Prevent attaching to kernel threads

We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.

Found while analysing the fallout of Dave Jones syscall fuzzer.

We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.

Change-Id: I03941dc5737bcb9d3ddd2ec88f7c263c27a1247d
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
futex: Add another early deadlock detection check

Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
  http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com

That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
    - it can detect that issue early
    - it avoids a different and more complex fixup for backing out

If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.

The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.

Change-Id: I5242efcdc3c08159c652fe645e1f85b27687e6ca
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.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.

Change-Id: I473bf486ad451de0bfd049a110b69795a6fda451
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>
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. ]

Change-Id: Ic8714ed2e9dee323a011eed42f7c0159c65dfbf3
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>