CHROMIUM: mm: Fix calculation of dirtyable memory

The system uses global_dirtyable_memory() to calculate
number of dirtyable pages/pages that can be allocated
to the page cache.  A bug causes an underflow thus making
the page count look like a big unsigned number.  This in turn
confuses the dirty writeback throttling to aggressively write
back pages as they become dirty (usually 1 page at a time).

Fix is to ensure there is no underflow while doing the math.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Puneet Kumar <puneetster@chromium.org>

BUG=chrome-os-partner:16011
TEST=Manual; boot kernel, powerwash, login with testaccount and
make sure no jank occurs on sync of applications

Change-Id: I614e7c3156e014f0f28a4ef9bdd8cb8a2cd07b2a
Reviewed-on: https://gerrit.chromium.org/gerrit/37612
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Ready: Puneet Kumar <puneetster@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Tested-by: Puneet Kumar <puneetster@chromium.org>

Conflicts:
	mm/page-writeback.c
OMAP4: PM: Fix missed PRCM MPU interrupt events

OMAP PRCM detects events with EDGE sensitivity. Edge sensitivity
requires to clear the interrupt event status bit before acknowledging
the source event.
If the source event is cleared (1) before reseting the interrupt event
status bit (2), then a subsequent source event (i.e edge) between (1)
and (2) would be missed. Then, all the source events would be kept
"masked" until the source event is cleared again.

The bug seen here is that upon two consecutive PRCM interrupt events
from the IO daisy chain source event, the second event is missed if it
occurs before the PRCM interrupt event status is cleared.
Since the IO daisy chain source event has not been acknowledged, the
subseqent events from this source are missed too.

This patch fix the PRCM interrupt handler by acknowledging the interrupt
event status bit before clearing the source event.

Change-Id: I8c43a93c3b6c7c654ddaa262b7c1c3e7385da158
Signed-off-by: Patrick Combes <p-combes@ti.com>
Signed-off-by: Cedric Poignet <c-poignet@ti.com>
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>
ARM: 7178/1: fault.c: Port OOM changes into do_page_fault

Commit d065bd810b6deb67d4897a14bfe21f8eb526ba99
(mm: retry page fault when blocking on disk transfer) and
commit 37b23e0525d393d48a7d59f870b3bc061a30ccdb
(x86,mm: make pagefault killable)

The above commits introduced changes into the x86 pagefault handler
for making the page fault handler retryable as well as killable.

These changes reduce the mmap_sem hold time, which is crucial
during OOM killer invocation.

Port these changes to ARM.

Without these changes, my ARM board encounters many hang and livelock
scenarios.
After applying this patch, OOM feature performance improves according to
my testing.

Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:

	arch/arm/mm/fault.c
modified for Tuna kernel from Mainline by faux123
readahead: fault retry breaks mmap file read random detection

.fault now can retry.  The retry can break state machine of .fault.  In
filemap_fault, if page is miss, ra->mmap_miss is increased.  In the second
try, since the page is in page cache now, ra->mmap_miss is decreased.  And
these are done in one fault, so we can't detect random mmap file access.

Add a new flag to indicate .fault is tried once.  In the second try, skip
ra->mmap_miss decreasing.  The filemap_fault state machine is ok with it.

I only tested x86, didn't test other archs, but looks the change for other
archs is obvious, but who knows :)

Signed-off-by: Shaohua Li <shaohua.li@xxxxxxxxxxxx>
Cc: Rik van Riel <riel@xxxxxxxxxx>
Cc: Wu Fengguang <fengguang.wu@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
modified for Tuna kernel from Linux Mainline by faux123
hrtimer: Consider preemption when migrating hrtimer cpu_bases

When switching to a new cpu_base in switch_hrtimer_base(), we
briefly enable preemption by unlocking the cpu_base lock in two
places. During this interval it's possible for the running thread
to be swapped to a different CPU.

Consider the following example:

CPU #0                                 CPU #1
----                                   ----
hrtimer_start()                        ...
 lock_hrtimer_base()
 switch_hrtimer_base()
  this_cpu = 0;
  target_cpu_base = 0;
  raw_spin_unlock(&cpu_base->lock)
<migrate to CPU 1>
...                                    this_cpu == 0
                                       cpu == this_cpu
                                       timer->base = CPU #0
                                       timer->base != LOCAL_CPU

Since the cached this_cpu is no longer accurate, we'll skip the
hrtimer_check_target() check. Once we eventually go to program
the hardware, we'll decide not to do so since it knows the real
CPU that we're running on is not the same as the chosen base. As
a consequence, we may end up missing the hrtimer's deadline.

Fix this by updating the local CPU number each time we retake a
cpu_base lock in switch_hrtimer_base().

Another possibility is to disable preemption across the whole of
switch_hrtimer_base.  This looks suboptimal since preemption
would be disabled while waiting for lock(s).

Change-Id: I3f76d528ab2288ef5f950f4d048e7f3fa6cf1228
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
hrtimer: Prevent enqueue of hrtimer on dead CPU

When switching the hrtimer cpu_base, we briefly allow for
preemption to become enabled by unlocking the cpu_base lock.
During this time, the CPU corresponding to the new cpu_base
that was selected may in fact go offline. In this scenario, the
hrtimer is enqueued to a CPU that's not online, and therefore
it never fires.

As an example, consider this example:

CPU #0                          CPU #1
----                            ----
...                             hrtimer_start()
                                 lock_hrtimer_base()
                                 switch_hrtimer_base()
                                  cpu = hrtimer_get_target() -> 1
                                  spin_unlock(&cpu_base->lock)
                                <migrate thread to CPU #0>
                                <offline>
spin_lock(&new_base->lock)
this_cpu = 0
cpu != this_cpu
enqueue_hrtimer(cpu_base #1)

To prevent this scenario, verify that the CPU corresponding to
the new cpu_base is indeed online before selecting it in
hrtimer_switch_base(). If it's not online, fallback to using the
base of the current CPU.

Change-Id: I6359cb299ba7e08abf25d3360fcdd925b4c03b69
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Hybla TCPC tweaks
Hybla TCP Congestion fixes