Makefile: arch/arm/boot/compressed: *squashing updates from ARM-software*
Makefile: *updating GCC flags*
defconfig: *update*
*squashing some fixes and reverts*

msm: avs: Remove vestigial software based AVS

      Older targets like 8x50 had the first version of Apdaptive Voltage
      Scaling done in software. This feature was never enabled and supported.
      Remove the code and the associated config items.

      Change-Id: If3bdab7d0bdb5d51e099f7c37f56592826edc102
      Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>

drivers: msm_nand: *silence GCC warnings*

      Signed-off-by: moddingg33k <moddingg33k@t-online.de>

fs: ext4: reverting huawei specific changes

      Signed-off-by: moddingg33k <moddingg33k@t-online.de>

msm: acpuclock: Add a null check for acpuclk_data

      If acpuclock fails to probe before a client calls acpuclk_get_rate,
      a null dereference will occur. Fix this by adding the appropriate
      checks.

      Change-Id: If873a64711e9cc807b1734996f7c9358bb08161a
      Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>

Revert "ARM: armv7 no need update SCTLR for alignment"

      This reverts commit 6dfaacc2dc708f11863d144ac41882af4315d4df.

PM / tracing: remove deprecated power trace API

      The text in Documentation said it would be removed in 2.6.41;
      the text in the Kconfig said removal in the 3.1 release.  Either
      way you look at it, we are well past both, so push it off a cliff.

      Note that the POWER_CSTATE and the POWER_PSTATE are part of the
      legacy tracing API.  Remove all tracepoints which use these flags.
      As can be seen from context, most already have a trace entry via
      trace_cpu_idle anyways.

      Also, the cpufreq/cpufreq.c PSTATE one is actually unpaired, as
      compared to the CSTATE ones which all have a clear start/stop.
      As part of this, the trace_power_frequency also becomes orphaned,
      so it too is deleted.

      Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: ondemand: reverted huawei changes
arm/crypto: Add optimized AES and SHA1 routines

arm/crypto: Add optimized AES and SHA1 routines

      Add assembler versions of AES and SHA1 for ARM platforms.  This has provided
      up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.

      Platform   CPU SPeed    Endian   Before (bps)   After (bps)   Improvement

      IXP425      533 MHz      big     11217042        15566294        ~38%
      KS8695      166 MHz     little    3828549         5795373        ~51%

      Signed-off-by: David McCullough <ucdevel@gmail.com>
      Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

ARM: 7626/1: arm/crypto: Make asm SHA-1 and AES code Thumb-2 compatible

      This patch fixes aes-armv4.S and sha1-armv4-large.S to work
      natively in Thumb.  This allows ARM/Thumb interworking workarounds
      to be removed.

      I also take the opportunity to convert some explicit assembler
      directives for exported functions to the standard
      ENTRY()/ENDPROC().

      For the code itself:

	* In sha1_block_data_order, use of TEQ with sp is deprecated in
	  ARMv7 and not supported in Thumb.  For the branches back to
	  .L_00_15 and .L_40_59, the TEQ is converted to a CMP, under the
	  assumption that clobbering the C flag here will not cause
	  incorrect behaviour.

	  For the first branch back to .L_20_39_or_60_79 the C flag is
	  important, so sp is moved temporarily into another register so
	  that TEQ can be used for the comparison.

	* In the AES code, most forms of register-indexed addressing with
	  shifts and rotates are not permitted for loads and stores in
	  Thumb, so the address calculation is done using a separate
	  instruction for the Thumb case.

      The resulting code is unlikely to be optimally scheduled, but it
      should not have a large impact given the overall size of the code.
      I haven't run any benchmarks.

      Signed-off-by: Dave Martin <dave.martin@linaro.org>
      Tested-by: David McCullough <ucdevel@gmail.com> (ARM only)
      Acked-by: David McCullough <ucdevel@gmail.com>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling

      Make the SHA1 asm code ABI conformant by making sure all stack
      accesses occur above the stack pointer.

      Origin:
      http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1a9d60d2

      Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7837/3: fix Thumb-2 bug in AES assembler code

      Patch 638591c enabled building the AES assembler code in Thumb2 mode.
      However, this code used arithmetic involving PC rather than adr{l}
      instructions to generate PC-relative references to the lookup tables,
      and this needs to take into account the different PC offset when
      running in Thumb mode.

      Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

      ARM: move AES typedefs and function prototypes to separate header

      Put the struct definitions for AES keys and the asm function prototypes in a
      separate header and export the asm functions from the module.
      This allows other drivers to use them directly.

      Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

      ARM: add support for bit sliced AES using NEON instructions

      Bit sliced AES gives around 45% speedup on Cortex-A15 for encryption
      and around 25% for decryption. This implementation of the AES algorithm
      does not rely on any lookup tables so it is believed to be invulnerable
      to cache timing attacks.

      This algorithm processes up to 8 blocks in parallel in constant time. This
      means that it is not usable by chaining modes that are strictly sequential
      in nature, such as CBC encryption. CBC decryption, however, can benefit from
      this implementation and runs about 25% faster. The other chaining modes
      implemented in this module, XTS and CTR, can execute fully in parallel in
      both directions.

      The core code has been adopted from the OpenSSL project (in collaboration
      with the original author, on cc). For ease of maintenance, this version is
      identical to the upstream OpenSSL code, i.e., all modifications that were
      required to make it suitable for inclusion into the kernel have been made
      upstream. The original can be found here:

	  http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f6a6130

      Note to integrators:
      While this implementation is significantly faster than the existing table
      based ones (generic or ARM asm), especially in CTR mode, the effects on
      power efficiency are unclear as of yet. This code does fundamentally more
      work, by calculating values that the table based code obtains by a simple
      lookup; only by doing all of that work in a SIMD fashion, it manages to
      perform better.

      Cc: Andy Polyakov <appro@openssl.org>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

ARM: add .gitignore entry for aesbs-core.S

      This avoids this file being incorrectly added to git.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

CRYPTO: Fix more AES build errors

      Building a multi-arch kernel results in:

      arch/arm/crypto/built-in.o: In function `aesbs_xts_decrypt':
      sha1_glue.c:(.text+0x15c8): undefined reference to `bsaes_xts_decrypt'
      arch/arm/crypto/built-in.o: In function `aesbs_xts_encrypt':
      sha1_glue.c:(.text+0x1664): undefined reference to `bsaes_xts_encrypt'
      arch/arm/crypto/built-in.o: In function `aesbs_ctr_encrypt':
      sha1_glue.c:(.text+0x184c): undefined reference to `bsaes_ctr32_encrypt_blocks'
      arch/arm/crypto/built-in.o: In function `aesbs_cbc_decrypt':
      sha1_glue.c:(.text+0x19b4): undefined reference to `bsaes_cbc_encrypt'

      This code is already runtime-conditional on NEON being supported, so
      there's no point compiling it out depending on the minimum build
      architecture.

      Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

crypto: create generic version of ablk_helper

      Create a generic version of ablk_helper so it can be reused
      by other architectures.

      Acked-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
      Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
byteorder: allow arch to opt to use GCC intrinsics for byteswapping

Since GCC 4.4, there have been __builtin_bswap32() and __builtin_bswap16()
intrinsics. A __builtin_bswap16() came a little later (4.6 for PowerPC,
48 for other platforms).

By using these instead of the inline assembler that most architectures
have in their __arch_swabXX() macros, we let the compiler see what's
actually happening. The resulting code should be at least as good, and
much *better* in the cases where it can be combined with a nearby load
or store, using a load-and-byteswap or store-and-byteswap instruction
(e.g. lwbrx/stwbrx on PowerPC, movbe on Atom).

When GCC is sufficiently recent *and* the architecture opts in to using
the intrinsics by setting CONFIG_ARCH_USE_BUILTIN_BSWAP, they will be
used in preference to the __arch_swabXX() macros. An architecture which
does not set ARCH_USE_BUILTIN_BSWAP will continue to use its own
hand-crafted macros.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
binfmt_elf.c: use get_random_int() to fix entropy depleting.

Usually the entropy pool depletes very fast and stays in the 100-200 range.
After this patch, the entropy stays in the 600-1000 range without the risk of
depleting in normal workloads.

Change-Id: Ice0d0f14691046249d7b4a4d31af98ab80c6306b
suspend: enable freeze timeout configuration through sys

At present, the value of timeout for freezing is 20s, which is
meaningless in case that one thread is frozen with mutex locked
and another thread is trying to lock the mutex, as this time of
freezing will fail unavoidably.
And if there is no new wakeup event registered, the system will
waste at most 20s for such meaningless trying of freezing.

With this patch, the value of timeout can be configured to smaller
value, so such meaningless trying of freezing will be aborted in
earlier time, and later freezing can be also triggered in earlier
time. And more power will be saved.
In normal case on mobile phone, it costs real little time to freeze
processes. On some platform, it only costs about 20ms to freeze
user space processes and 10ms to freeze kernel freezable threads.

Signed-off-by: Liu Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Li Fei <fei.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
freezer: *squashing updates by Colin Cross (05/2013)*

freezer: add unsafe versions of freezable helpers for NFS

      NFS calls the freezable helpers with locks held, which is unsafe
      and will cause lockdep warnings when 6aa9707 "lockdep: check
      that no locks held at freeze time" is reapplied (it was reverted
      in dbf520a).  NFS shouldn't be doing this, but it has
      long-running syscalls that must hold a lock but also shouldn't
      block suspend.  Until NFS freeze handling is rewritten to use a
      signal to exit out of the critical section, add new *_unsafe
      versions of the helpers that will not run the lockdep test when
      6aa9707 is reapplied, and call them from NFS.

      In practice the likley result of holding the lock while freezing
      is that a second task blocked on the lock will never freeze,
      aborting suspend, but it is possible to manufacture a case using
      the cgroup freezer, the lock, and the suspend freezer to create
      a deadlock.  Silencing the lockdep warning here will allow
      problems to be found in other drivers that may have a more
      serious deadlock risk, and prevent new problems from being added.

      Signed-off-by: Colin Cross <ccross@android.com>
      Acked-by: Pavel Machek <pavel@ucw.cz>
      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

freezer: add unsafe versions of freezable helpers for CIFS

      CIFS calls wait_event_freezekillable_unsafe with a VFS lock held,
      which is unsafe and will cause lockdep warnings when 6aa9707
      "lockdep: check that no locks held at freeze time" is reapplied
      (it was reverted in dbf520a).  CIFS shouldn't be doing this, but
      it has long-running syscalls that must hold a lock but also
      shouldn't block suspend.  Until CIFS freeze handling is rewritten
      to use a signal to exit out of the critical section, add a new
      wait_event_freezekillable_unsafe helper that will not run the
      lockdep test when 6aa9707 is reapplied, and call it from CIFS.

      In practice the likley result of holding the lock while freezing
      is that a second task blocked on the lock will never freeze,
      aborting suspend, but it is possible to manufacture a case using
      the cgroup freezer, the lock, and the suspend freezer to create
      a deadlock.  Silencing the lockdep warning here will allow
      problems to be found in other drivers that may have a more
      serious deadlock risk, and prevent new problems from being added.

      Acked-by: Pavel Machek <pavel@ucw.cz>
      Acked-by: Tejun Heo <tj@kernel.org>
      Reviewed-by: Jeff Layton <jlayton@redhat.com>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

lockdep: remove task argument from debug_check_no_locks_held

      The only existing caller to debug_check_no_locks_held calls it
      with 'current' as the task, and the freezer needs to call
      debug_check_no_locks_held but doesn't already have a current
      task pointer, so remove the argument.  It is already assuming
      that the current task is relevant by dumping the current stack
      trace as part of the warning.

      This was originally part of 6aa9707099c (lockdep: check that
      no locks held at freeze time) which was reverted in
      dbf520a9d7d4.

      Original-author: Mandeep Singh Baines <msb@chromium.org>
      Acked-by: Pavel Machek <pavel@ucw.cz>
      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

freezer: shorten freezer sleep time using exponential backoff

      All tasks can easily be frozen in under 10 ms, switch to using
      an initial 1 ms sleep followed by exponential backoff until
      8 ms.  Also convert the printed time to ms instead of centiseconds.

      Acked-by: Pavel Machek <pavel@ucw.cz>
      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

freezer: skip waking up tasks with PF_FREEZER_SKIP set

      Android goes through suspend/resume very often (every few seconds when
      on a busy wifi network with the screen off), and a significant portion
      of the energy used to go in and out of suspend is spent in the
      freezer.  If a task has called freezer_do_not_count(), don't bother
      waking it up.  If it happens to wake up later it will call
      freezer_count() and immediately enter the refrigerator.

      Combined with patches to convert freezable helpers to use
      freezer_do_not_count() and convert common sites where idle userspace
      tasks are blocked to use the freezable helpers, this reduces the
      time and energy required to suspend and resume.

      Acked-by: Tejun Heo <tj@kernel.org>
      Acked-by: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

freezer: convert freezable helpers to freezer_do_not_count()

      Freezing tasks will wake up almost every userspace task from
      where it is blocking and force it to run until it hits a
      call to try_to_sleep(), generally on the exit path from the syscall
      it is blocking in.  On resume each task will run again, usually
      restarting the syscall and running until it hits the same
      blocking call as it was originally blocked in.

      Convert the existing wait_event_freezable* wrappers to use
      freezer_do_not_count().  Combined with a previous patch,
      these tasks will not run during suspend or resume unless they wake
      up for another reason, in which case they will run until they hit
      the try_to_freeze() in freezer_count(), and then continue processing
      the wakeup after tasks are thawed.

      This results in a small change in behavior, previously a race
      between freezing and a normal wakeup would be won by the wakeup,
      now the task will freeze and then handle the wakeup after thawing.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

freezer: convert freezable helpers to static inline where possible

      Some of the freezable helpers have to be macros because their
      condition argument needs to get evaluated every time through
      the wait loop.  Convert the others to static inline to make
      future changes easier.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

freezer: add new freezable helpers using freezer_do_not_count()

      Freezing tasks will wake up almost every userspace task from
      where it is blocking and force it to run until it hits a
      call to try_to_sleep(), generally on the exit path from the syscall
      it is blocking in.  On resume each task will run again, usually
      restarting the syscall and running until it hits the same
      blocking call as it was originally blocked in.

      To allow tasks to avoid running on every suspend/resume cycle,
      this patch adds additional freezable wrappers around blocking calls
      that call freezer_do_not_count().  Combined with the previous patch,
      these tasks will not run during suspend or resume unless they wake
      up for another reason, in which case they will run until they hit
      the try_to_freeze() in freezer_count(), and then continue processing
      the wakeup after tasks are thawed.

      Additional patches will convert the most common locations that
      userspace blocks in to use freezable helpers.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

binder: use freezable blocking calls

      Avoid waking up every thread sleeping in a binder call during
      suspend and resume by calling a freezable blocking call.  Previous
      patches modified the freezer to avoid sending wakeups to threads
      that are blocked in freezable blocking calls.

      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

epoll: use freezable blocking call

      Avoid waking up every thread sleeping in an epoll_wait call during
      suspend and resume by calling a freezable blocking call.  Previous
      patches modified the freezer to avoid sending wakeups to threads
      that are blocked in freezable blocking calls.

      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

select: use freezable blocking call

      Avoid waking up every thread sleeping in a select call during
      suspend and resume by calling a freezable blocking call.  Previous
      patches modified the freezer to avoid sending wakeups to threads
      that are blocked in freezable blocking calls.

      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

futex: use freezable blocking call

      Avoid waking up every thread sleeping in a futex_wait call during
      suspend and resume by calling a freezable blocking call.  Previous
      patches modified the freezer to avoid sending wakeups to threads
      that are blocked in freezable blocking calls.

      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.

      Acked-by: Tejun Heo <tj@kernel.org>
      Acked-by: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: Darren Hart <dvhart@linux.intel.com>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

nanosleep: use freezable blocking call

      Avoid waking up every thread sleeping in a nanosleep call during
      suspend and resume by calling a freezable blocking call.  Previous
      patches modified the freezer to avoid sending wakeups to threads
      that are blocked in freezable blocking calls.

      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.

      Acked-by: Tejun Heo <tj@kernel.org>
      Acked-by: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

sigtimedwait: use freezable blocking call

      Avoid waking up every thread sleeping in a sigtimedwait call during
      suspend and resume by calling a freezable blocking call.  Previous
      patches modified the freezer to avoid sending wakeups to threads
      that are blocked in freezable blocking calls.

      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

af_unix: use freezable blocking calls in read

      Avoid waking up every thread sleeping in read call on an AF_UNIX
      socket during suspend and resume by calling a freezable blocking
      call.  Previous patches modified the freezer to avoid sending
      wakeups to threads that are blocked in freezable blocking calls.

      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.

      Acked-by: Tejun Heo <tj@kernel.org>
      Signed-off-by: Colin Cross <ccross@android.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

HACK: ARM: disable sleeping while atomic warning in do_signal

      ARM disables interrupts in do_signal, which triggers a warning in
      try_to_freeze, see details at https://lkml.org/lkml/2011/8/23/221.
      To prevent the warnings, add try_to_freeze_nowarn and call it from
      do_signal.

      Change-Id: If7482de21c386adc705fa1ac4ecb8c7ece5bb356
      Signed-off-by: Colin Cross <ccross@android.com>
introduce for_each_thread() to replace the buggy while_each_thread()

while_each_thread() and next_thread() should die, almost every lockless
usage is wrong.

1. Unless g == current, the lockless while_each_thread() is not safe.

   while_each_thread(g, t) can loop forever if g exits, next_thread()
   can't reach the unhashed thread in this case. Note that this can
   happen even if g is the group leader, it can exec.

2. Even if while_each_thread() itself was correct, people often use
   it wrongly.

   It was never safe to just take rcu_read_lock() and loop unless
   you verify that pid_alive(g) == T, even the first next_thread()
   can point to the already freed/reused memory.

This patch adds signal_struct->thread_head and task->thread_node to
create the normal rcu-safe list with the stable head.  The new
for_each_thread(g, t) helper is always safe under rcu_read_lock() as
long as this task_struct can't go away.

Note: of course it is ugly to have both task_struct->thread_node and the
old task_struct->thread_group, we will kill it later, after we change
the users of while_each_thread() to use for_each_thread().

Perhaps we can kill it even before we convert all users, we can
reimplement next_thread(t) using the new thread_head/thread_node.  But
we can't do this right now because this will lead to subtle behavioural
changes.  For example, do/while_each_thread() always sees at least one
task, while for_each_thread() can do nothing if the whole thread group
has died.  Or thread_group_empty(), currently its semantics is not clear
unless thread_group_leader(p) and we need to audit the callers before we
can change it.

So this patch adds the new interface which has to coexist with the old
one for some time, hopefully the next changes will be more or less
straightforward and the old one will go away soon.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Sergey Dyasly <dserrg@gmail.com>
Tested-by: Sergey Dyasly <dserrg@gmail.com>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Acked-by: David Rientjes <rientjes@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mandeep Singh Baines <msb@chromium.org>
Cc: "Ma, Xindong" <xindong.ma@intel.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
android: lowmemorykiller: *update*

android/lowmemorykiller: Check all tasks for death pending

      The lowmemorykiller uses the TIF_MEMDIE flag to help ensure it doesn't
      kill another task until the memory from the previously killed task has
      been returned to the system.

      However the lowmemorykiller does not currently look at tasks who do not
      have a tasks->mm, but just because a process doesn't have a tasks->mm
      does not mean that the task's memory has been fully returned to the
      system yet.

      In order to prevent the lowmemorykiller from unnecessarily killing
      multiple applications in a row the lowmemorykiller has been changed to
      ensure that previous killed tasks are no longer in the process list
      before attempting to kill another task.

      Change-Id: I7d8a8fd39ca5625e6448ed2efebfb621f6e93845
      Signed-off-by: Liam Mark <lmark@codeaurora.org>

staging: android: lowmemorykiller: Add config option to support oom_adj values

      The conversion to use oom_score_adj instead of the deprecated oom_adj
      values breaks existing user-space code. Add a config option to convert
      oom_adj values written to oom_score_adj values if they appear to be
      valid oom_adj values.

      Change-Id: I68308125059b802ee2991feefb07e9703bc48549
      CRs-Fixed: 389463
      Signed-off-by: Arve Hjønnevåg <arve@android.com>
      Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

staging: android: lowmemorykiller: Reduce debug_level to 1

      Under certain circumstances, such as after the lowmemorykiller
      has recently killed an application, the logs can get flooded
      with "select to kill" messages.

      Change-Id: I7ae1de47c77d929e04b99be3432577d4f5fd1b2d
      Signed-off-by: Liam Mark <lmark@codeaurora.org>

android/lowmemorykiller: Wait for memory to be freed

      The memory reclaim code needs to give time to the system to
      return the memory from a killed process otherwise the memory
      reclaim code could run continuously, in multiple threads,
      which could starve both the watchdog thread and the thread
      which is responsible for returning the memory from the
      killed process.

      Change-Id: Ieded4bfe038ca936247fa4b638070e979b02eaa1
      CRs-fixed: 447740
      Signed-off-by: Liam Mark <lmark@codeaurora.org>

android/lowmemorykiller: Ignore tasks with freed mm

      A killed task can stay in the task list long after its
      memory has been returned to the system, therefore
      ignore any tasks whose mm struct has been freed.

      Change-Id: I76394b203b4ab2312437c839976f0ecb7b6dde4e
      CRs-fixed: 450383
      Signed-off-by: Liam Mark <lmark@codeaurora.org>

android: lowmemorykiller: add lmk parameters tunning code.

      There are cases that LMK doesn't run, even when it must run.
      It is due to LMK shrinker not considering memory status per zone.
      So add LMK parameters(other_free, other_file) tunnig code to
      consider target zone of LMK shrinker.

      Change-Id: I6f1f8660d5da920a0e3af45a160499965032081d
      Git-commit: 22d990a58fc17b3f0155e15eb2dc3efa037bea1c
      Git-repo: https://android.googlesource.com/kernel/common/
      [ohaugan@codeaurora.org: Fix compilation issues]
      Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>

android/lowmemorykiller: Account for total_swapcache_pages

      The lowmemorykiller relies on NR_FILE_PAGES when measureing
      the amount of reclaimable memory in the system.
      However when swap is enabled swap cache pages are counted
      in NR_FILE_PAGES, and swap cache pages aren't as reclaimable
      in low memory as file cache pages. Therefore a large swap
      cache can result in the lowmemorykiller not running and
      an OOM occuring.

      In order to ensure the lowmemorykiller properly evaluates the
      amount of reclaimable memory don't count the swap cache pages.

      Change-Id: I38239283e572f814b277c718eaf6be7f92abacbb
      Signed-off-by: Liam Mark <lmark@codeaurora.org>

mm, oom: change type of oom_score_adj to short

      The maximum oom_score_adj is 1000 and the minimum oom_score_adj is -1000,
      so this range can be represented by the signed short type with no
      functional change.  The extra space this frees up in struct signal_struct
      will be used for per-thread oom kill flags in the next patch.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

staging: android: lowmemorykiller: well-marked debug print

      Add "lowmemorykiller:" prefix to the debug print so it's easier to
      analyse LMK's debug output:
      dmesg | grep lowmemorykiller

      Signed-off-by: Dmitry Voytik <dvv.kernel@gmail.com>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android: lowmemorykiller: set TIF_MEMDIE before send kill sig

      Set TIF_MEMDIE tsk_thread flag before send kill signal to the
      selected thread. This is to fit a usual code sequence and avoid
      potential race issue.

      Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
      Acked-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

lowmemorykiller: make default lowmemorykiller debug message useful

      lowmemorykiller debug messages are inscrutable and mostly useful
      for debugging the lowmemorykiller, not explaining why a process
      was killed.  Make the messages more useful by prefixing them
      with "lowmemorykiller: " and explaining in more readable terms
      what was killed, who it was killed for, and why it was killed.

lowmemorykiller.c: convert to use for_each_thread

      Signed-off-by: Paul Reioux <reioux@gmail.com>
msm: cpufreq: *squashing updates*

msm: cpufreq: fix a race between hotplug and cpufreq

      When msm_cpufreq_target() is called without holding the policy
      semaphore, there is a rare chance that the cpu gets hotplugged in
      the acpuclk_set_rate. The probability of this issue increases
      when cross-calling is used or using interactive governor which
      tries to set all cpu frequencies from a single thread.

      Add a hotplug notifier and set the device_suspended flag holding
      the suspend mutex, when cpu is going down. This mutex is always
      held when frequency changes are done.

      Change-Id: Ide3aa6927ad60d2512d63761c51bb15117461250
      Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

msm: cpufreq: increase priority of thread that increases frequencies

      When the cpufreq governors request for increase in frequency from kworker
      threads, there is chance that the kworker thread is cpu starved due to
      other high priority threads, leading to undesirable increase in frequency
      ramp-up latency. Add the calling thread to SCHED_FIFO policy when
      requesting for increase in frequency and restore back to original policy
      after ramp-up is completed.

      Change-Id: Ie4fa199b7f9087717cb94dfcc2eddea27cc0012b
      Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

msm: cpufreq: Always update frequency limits when core is online

      Remove condition in msm_cpufreq_init() so that when cpu is set to
      online, it will call set_cpu_freq() and update the frequency limits.

      CRs-Fixed: 462816
      Change-Id: I40ac33c9cb4b42590a83f9d61b74f23379f5642e
      Signed-off-by: Jennifer Liu <chihning@codeaurora.org>

msm: cpufreq: Configure WQ for higer priority

      When the workqueue runs at a lower priority, it gets starved by higher
      priority threads. Bump the WQ priority to high to ensure cpufreq work
      queue gets a fair scheduling chance

      Change-Id: I9e994da94a347dceb884e72ec3dd3da468a4471d
      Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>

msm: cpufreq: Remove unused msm_cpufreq_set_freq_limits() API

      The msm_cpufreq_set_freq_limits() is a mach specific way to set CPU freq
      limits. The thermal code no longer uses this API and instead uses the
      standard INCOMPATIBLE notifiers provided by the common CPUfreq framework.
      Since this API is no longer needed, delete it.

      Change-Id: I5c07b17195d4e4b75cdd4d82f8e7cb6cb6f3e199
      Signed-off-by: Saravana Kannan <skannan@codeaurora.org>

msm: cpufreq: Implement suspend/resume for cpufreq driver

      Cpufreq suspend variable get's updated in kernel pm notifier
      callback which gets called in process context. This will create
      window where cpufreq governor may try to change the frequency
      before suspend variable is updated while resume.

      Define suspend/resume for cpufreq driver to update suspend variable
      in atomic context.

      Don't update the policy->cur upon cpufreq driver failure.

      CRs-fixed: 423791
      Change-Id: Id78705f5c3b8bf801c6253e9362299280903769f
      Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: framebuffer: *deprecate huawei's self_adapt feature*

      -revert huawei specific modifications
      -tweaked buffers for 800*400 display*

      Signed-off-by: moddingg33k <moddingg33k@t-online.de>

msm_fb: Add support for shared GPIO on SKU3/SKU3-1/SKU7

      Use virtual regulator support for shared GPIOs between display
      and camera on SKU3, SKU3-1 and SKU7 variants.

      CRs-fixed: 384271
      Change-Id: If40401ca68299e974bce9daab599bcf5839ff662
      Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>

msm_fb: Disable continuous splash screen for QRD SKU3

      Currently there is no support for splash screen in LK for
      QRD SKU3 devices. Hence, disable continuous splash screen
      feature on SKU3 devices.

      Change-Id: Idb9b004f709a13529cc42bd225a741428863e420
      Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>

board-msm7627a: display: Add settling delay for display resume.

      This change adds minimal delay to allow for settling time
      of MIPI DSI Bridge reset chip after it comes out of the
      reset sequence.

      CRs-fixed: 405241
      Change-Id: I577e68abc926a8f6d6987d7d016922fa0b31f846
      Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
cpufreq: ondemand: *squashing updates*

cpufreq: ondemand: Fix kernel warning in cpufreq_governor_dbs

      GOV_STOP event destroys the timer_mutex and is not initialized back
      upon GOV_START event.
      The Kernel complains at mutex_lock(during GOV_LIMITS event) after
      mutex_destroy.

      [<c0014918>] (unwind_backtrace+0x0/0x11c)
      [<c007c004>] (warn_slowpath_common+0x4c/0x64)
      [<c007c034>] (warn_slowpath_null+0x18/0x1c)
      [<c079eef8>] (__mutex_lock_slowpath+0x130/0x3c4)
      [<c079f1ac>] (mutex_lock+0x20/0x3c) from [<c0540900>]
      [<c0540900>] (cpufreq_governor_dbs+0x3c8/0x468)
      [<c053d500>] (__cpufreq_governor+0x90/0xe0)
      [<c053d774>] (__cpufreq_set_policy+0x224/0x258)
      [<c053da58>] (cpufreq_add_dev_interface+0x2b0/0x308)
      [<c053e784>] (cpufreq_add_dev+0x500/0x56c)
      [<c079247c>] (cpufreq_cpu_callback+0x88/0x9c)
      [<c07a2ca8>] (notifier_call_chain+0x38/0x68)
      [<c007ded0>] (__cpu_notify+0x28/0x40)
      [<c0790024>] (_cpu_up+0xe4/0x118)
      [<c0790024>] (cpu_up+0x64/0x80)
      [<c0765840>] (store_online+0x48/0x78)
      [<c038d0c8>] (dev_attr_store+0x18/0x24)
      [<c017be40>] (sysfs_write_file+0x108/0x13c)
      [<c012cdfc>] (vfs_write+0xb0/0x128)
      [<c012d034>](sys_write+0x38/0x64)

      Change-Id: Ie2a796b17209243de731ccf2ab04b7f9e7048df8
      Signed-off-by: Anji Jonnala <anjir@codeaurora.org>

msm: cpufreq: make the gov stop part fully atomic

      In the function cpufreq_governor_dbs, the case CPUFREQ_GOV_STOP
      is not completely atomic. The removal of sysfs is outside the
      critical path. If a START/STOP done frequently from user space
      then there is chance of adding the sysfs interface before removal.
      This creates a warning from sysfs saying creating an already
      existing entry.

      Also once it fails to create, cpufreq_governor_dbs returns with
      error code. The dbs_enable value is incremented which is not
      rolled back and cpufreq core tries to set the old
      governor. This might create further problems.

      Hence the removal of sysfs entry should happen in the critical
      path.

      CRs-fixed: 440969
      Change-Id: I98891756caf2ce0b85e39e9b4f58034af1ed97ce
      Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>

cpufreq: Use dedicated high-priority workqueues

      In the process of scaling CPU frequencies, cpufreq and the APIS is
      calls may hold resources that will prevent threads critical for
      system stability from running.

      Specifically, thermal-mitigation software may need to respond
      quickly to high-temperature conditions and throttle the CPU speed
      in an effort to cool down. If the system is already in the middle
      of a CPU frequency switch being executed on behalf of a cpufreq
      governor, thermal mitigation will be blocked until the scaling
      action has completed. If the system is under heave load of medium
      or high-priority threads, this may take a long while and the system
      may potentially surpass thermal limits in the meantime.

      Resolve this by using high priority workqueues for all ondemand
      and conservative governor scaling operations.  This will allow them
      to complete promptly and release their hold on resources necessary
      for maintaining system stability.

      Change-Id: I2f56052c131442838036cf4cdd8059f7c09bb805
      Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

cpufreq: ondemand: Fix store_powersave_bias() race with hotplug

      store_powersave_bias() assumes that CPUs will not be taken offline or
      brought online while executing its for_each_online_cpu() loops. Fix
      this race by blocking hotplug while executing in these loop.

      CRs-Fixed: 494407
      Change-Id: I0d5520444ec21a8d9b12fb73c06ac8442449fa85
      Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

      cpufreq: ondemand: Fix locking in store_powersave_bias

      store_powersave_bias() assumes that dbs_info->cur_policy will
      not change while it is executing. If it does, memory corruption
      can potentially result. Fix this by acquiring the dbs_lock.

      Most noticeably, this resolves timer-related list corruptions
      encountered when queue_delayed_work_on() is called from within
      store_powersave_bias() while a CPU is being hotplugged in and
      out.

      CRs-Fixed: 494407
      Change-Id: I0fd5cbef6834545274cad9481e574ec50b37b871
      Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

cpufreq: ondemand: Fix locking issue in store_powersave_bias

      store_powersave_bias takes timer_mutex before calling dbs_timer_exit
      which tries to cancel the delayed work do_dbs_timer which in turn
      tries to take the same lock. This can cause a lock recursion under
      the race condition where can cancel_delayed_work_sync is called
      when the work has already started executing.

      This can be avoided by taking that lock after calling
      dbs_timer_exit.

      Change-Id: I7f862286e66f1ddc1e13e4eeee369dd188fc10d5
      Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>

cpufreq: ondemand: Boost CPU frequency only for touch input

      Originally CPU frequency were boosted for any input event.
      In some case, sensor sends a lot of input event, which
      keep CPU in high frequency.  CPU frequency only need to
      be boosted when real user interaction happens.

      Change-Id: Ia3ad755b98d8363a17729926610b5dd6f0075288
      CR-Fixed: 507519
      Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>

cpufreq: ondemand: Fix update_sampling_rate race with hotplug

      update_sampling_rate has a for loop which goes through each
      online cpu and possibly queue up the ondemand work for them.
      But while doing this it doesnt take any hotplug lock which
      could potentially cause a race condition where ondemand work
      is queued after the hotplug code (which sets the policy to NULL)
      in the governor has cancelled any pending work. This could cause
      a crash while trying to access the NULL policy in dbs_check_cpu.

      Protecting the for_each_online_cpu loop with get_online_cpus()
      and put_online_cpus().

      Change-Id: Ia3f43ca7e4bed542834ab03ca1191d728f13311c
      Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>

cpufreq: ondemand: Fix hotplug deadlock with store_powersave_bias

      store_powersave_bias() acquires the hotplug lock and the dbs_mutex
      lock, but does so in the wrong order.  Deadlocks like the following
      can result.

      Thread A:
	  get_online_cpus+0x3c/0x5c           <- acquires 'cpu_hotplug.lock'
	  store_powersave_bias+0x80/0x3f4     <- acquires 'dbs_mutex'
	  kobj_attr_store+0x14/0x20
	  sysfs_write_file+0x108/0x13c
	  vfs_write+0xb0/0x128
	  sys_write+0x38/0x64

      Thread B:
	  cpufreq_governor_dbs+0x7c/0x55c     <- acquires 'dbs_mutex'
	  __cpufreq_governor+0x90/0xe0
	  __cpufreq_set_policy+0x1b0/0x258
	  cpufreq_add_dev_interface+0x2cc/0x334
	  cpufreq_add_dev+0x514/0x580
	  cpufreq_cpu_callback+0x88/0x9c
	  notifier_call_chain+0x38/0x68
	  __cpu_notify+0x28/0x40
	  _cpu_up+0xe4/0x118                  <- acquires 'cpu_hotplug.lock'
	  cpu_up+0x64/0x80
	  store_online+0x48/0x78
	  dev_attr_store+0x18/0x24
	  sysfs_write_file+0x108/0x13c
	  vfs_write+0xb0/0x128
	  sys_write+0x38/0x64

      Fix this by flipping the order in which the locks are acquired and
      released in store_powersave_bias so that it is the same as in the
      hotplug path.

      Change-Id: Idc59fb29d60b8f7fceb8ed0f2bb9eff4670abda7
      Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

cpufreq: ondemand: add input_boost interface

      Currently Ondemand governor handles any input event
      like touch by scaling the CPU frequency to maximum
      available on the target.

      This change adds a new sysfs interface "input_boost"
      whereby the CPU will scale to this frequency on input events.
      The value of this sysfs is user defined so input events
      can now be handled by scaling the CPU to lower frequencies
      than target max.

      Change-Id: I5428fd8797c9984b17a66b01a44557f2160e8b68
      Signed-off-by: Dilip Gudlur <dgudlur@codeaurora.org>

cpufreq: ondemand: fix timer-related list corruption in store_powersave_bias()

      The dbs_timer_init() call in store_powersave_bias() re-initializes the
      dbs_info workqueue, call on dbs_timer_exit() to ensure
      outstanding work is cleared prior to making this call. Also, grab the
      percpu timer_mutex lock to avoid race conditions with respect to the
      dbs timer.

      Change-Id: I79f3d43eeb51d2d8e21edd0fe043d6583333951f
      Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>

cpufreq: ondemand: Remove unnecessary synchronization attempt

      Commit 1ce28d6b (ondemand: updated tune for hardware coordination)
      brings in an attempt to synchronize expiry of per-cpu ondemand timer
      at same time across all online cpus. This is meant to help systems
      where "multiple cores share P-state via Hardware Coordination".

      Synchronization is achieved by having timers expire when jiffy value
      would be a perfect multiple of sampling window size. While such
      synchronozation attemps are unnecessary on systems where cores don't
      share P-states, it can hurt on power as cpus can now work off shorter
      sampling windows (when percentage utilization over short window can be
      observed to be high, causing frequency to be boosted).

      Remove this unnecessary attempt to synchronize expiry of ondemand
      timer across online cpus. A more acceptable solution could be to have
      low-level architecture specific cpufreq driver indicate the need for
      synchronization.

      Change-Id: I6cb1cf3472ca106f029dc01248e0df7cfbb495b8
      Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>

cpufreq: ondemand: Calculate iowait time only when necessary

	*backported for kernel 3.4.y*

	Signed-off-by: moddingg33k <moddingg33k@t-online.de>
mm, oom: *squashing updates from korg/linux-3.14.y

mm, oom: normalize oom scores to oom_score_adj scale only for userspace

      The oom_score_adj scale ranges from -1000 to 1000 and represents the
      proportion of memory available to the process at allocation time.  This
      means an oom_score_adj value of 300, for example, will bias a process as
      though it was using an extra 30.0% of available memory and a value of
      -350 will discount 35.0% of available memory from its usage.

      The oom killer badness heuristic also uses this scale to report the oom
      score for each eligible process in determining the "best" process to
      kill.  Thus, it can only differentiate each process's memory usage by
      0.1% of system RAM.

      On large systems, this can end up being a large amount of memory: 256MB
      on 256GB systems, for example.

      This can be fixed by having the badness heuristic to use the actual
      memory usage in scoring threads and then normalizing it to the
      oom_score_adj scale for userspace.  This results in better comparison
      between eligible threads for kill and no change from the userspace
      perspective.

      Suggested-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Tested-by: Dave Jones <davej@redhat.com>
      Signed-off-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: fix badness score underflow

      If the privileges given to root threads (3% of allowable memory) or a
      negative value of /proc/pid/oom_score_adj happen to exceed the amount of
      rss of a thread, its badness score overflows as a result of commit
      a7f638f999ff ("mm, oom: normalize oom scores to oom_score_adj scale only
      for userspace").

      Fix this by making the type signed and return 1, meaning the thread is
      still eligible for kill, if the value is negative.

      Reported-by: Dave Jones <davej@redhat.com>
      Acked-by: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: fix and cleanup oom score calculations

      The divide in p->signal->oom_score_adj * totalpages / 1000 within
      oom_badness() was causing an overflow of the signed long data type.

      This adds both the root bias and p->signal->oom_score_adj before doing the
      normalization which fixes the issue and also cleans up the calculation.

      Tested-by: Dave Jones <davej@redhat.com>
      Signed-off-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: fix kernel-doc warnings

      Fix kernel-doc warnings such as

	Warning(../mm/page_cgroup.c:432): No description found for parameter 'id'
	Warning(../mm/page_cgroup.c:432): Excess function parameter 'mem' description in 'swap_cgroup_record'

      Signed-off-by: Wanpeng Li <liwp@linux.vnet.ibm.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: do not schedule if current has been killed

      The oom killer currently schedules away from current in an uninterruptible
      sleep if it does not have access to memory reserves.  It's possible that
      current was killed because it shares memory with the oom killed thread or
      because it was killed by the user in the interim, however.

      This patch only schedules away from current if it does not have a pending
      kill, i.e.  if it does not share memory with the oom killed thread.  It's
      possible that it will immediately retry its memory allocation and fail,
      but it will immediately be given access to memory reserves if it calls the
      oom killer again.

      This prevents the delay of memory freeing when threads that share memory
      with the oom killed thread get unnecessarily scheduled.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: fix potential killing of thread that is disabled from oom killing

      /proc/sys/vm/oom_kill_allocating_task will immediately kill current when
      the oom killer is called to avoid a potentially expensive tasklist scan
      for large systems.

      Currently, however, it is not checking current's oom_score_adj value which
      may be OOM_SCORE_ADJ_MIN, meaning that it has been disabled from oom
      killing.

      This patch avoids killing current in such a condition and simply falls
      back to the tasklist scan since memory still needs to be freed.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: replace some information in tasklist dump

      The number of ptes and swap entries are used in the oom killer's badness
      heuristic, so they should be shown in the tasklist dump.

      This patch adds those fields and replaces cpu and oom_adj values that are
      currently emitted.  Cpu isn't interesting and oom_adj is deprecated and
      will be removed later this year, the same information is already displayed
      as oom_score_adj which is used internally.

      At the same time, make the documentation a little more clear to state this
      information is helpful to determine why the oom killer chose the task it
      did to kill.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: introduce helper function to process threads during scan

      This patch introduces a helper function to process each thread during the
      iteration over the tasklist.  A new return type, enum oom_scan_t, is
      defined to determine the future behavior of the iteration:

      - OOM_SCAN_OK: continue scanning the thread and find its badness,

      - OOM_SCAN_CONTINUE: do not consider this thread for oom kill, it's
	ineligible,

      - OOM_SCAN_ABORT: abort the iteration and return, or

      - OOM_SCAN_SELECT: always select this thread with the highest badness
	possible.

      There is no functional change with this patch.  This new helper function
      will be used in the next patch in the memory controller.

      Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: David Rientjes <rientjes@google.com>
      Reviewed-by: Sha Zhengju <handai.szj@taobao.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, memcg: introduce own oom handler to iterate only over its own threads

      The global oom killer is serialized by the per-zonelist
      try_set_zonelist_oom() which is used in the page allocator.  Concurrent
      oom kills are thus a rare event and only occur in systems using
      mempolicies and with a large number of nodes.

      Memory controller oom kills, however, can frequently be concurrent since
      there is no serialization once the oom killer is called for oom conditions
      in several different memcgs in parallel.

      This creates a massive contention on tasklist_lock since the oom killer
      requires the readside for the tasklist iteration.  If several memcgs are
      calling the oom killer, this lock can be held for a substantial amount of
      time, especially if threads continue to enter it as other threads are
      exiting.

      Since the exit path grabs the writeside of the lock with irqs disabled in
      a few different places, this can cause a soft lockup on cpus as a result
      of tasklist_lock starvation.

      The kernel lacks unfair writelocks, and successful calls to the oom killer
      usually result in at least one thread entering the exit path, so an
      alternative solution is needed.

      This patch introduces a seperate oom handler for memcgs so that they do
      not require tasklist_lock for as much time.  Instead, it iterates only
      over the threads attached to the oom memcg and grabs a reference to the
      selected thread before calling oom_kill_process() to ensure it doesn't
      prematurely exit.

      This still requires tasklist_lock for the tasklist dump, iterating
      children of the selected process, and killing all other threads on the
      system sharing the same memory as the selected victim.  So while this
      isn't a complete solution to tasklist_lock starvation, it significantly
      reduces the amount of time that it is held.

      Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: David Rientjes <rientjes@google.com>
      Reviewed-by: Sha Zhengju <handai.szj@taobao.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: reduce dependency on tasklist_lock

      Since exiting tasks require write_lock_irq(&tasklist_lock) several times,
      try to reduce the amount of time the readside is held for oom kills.  This
      makes the interface with the memcg oom handler more consistent since it
      now never needs to take tasklist_lock unnecessarily.

      The only time the oom killer now takes tasklist_lock is when iterating the
      children of the selected task, everything else is protected by
      rcu_read_lock().

      This requires that a reference to the selected process, p, is grabbed
      before calling oom_kill_process().  It may release it and grab a reference
      on another one of p's threads if !p->mm, but it also guarantees that it
      will release the reference before returning.

      [hughd@google.com: fix duplicate put_task_struct()]
      Signed-off-by: David Rientjes <rientjes@google.com>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, memcg: move all oom handling to memcontrol.c

      By globally defining check_panic_on_oom(), the memcg oom handler can be
      moved entirely to mm/memcontrol.c.  This removes the ugly #ifdef in the
      oom killer and cleans up the code.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Acked-by: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: allow exiting threads to have access to memory reserves

      Exiting threads, those with PF_EXITING set, can pagefault and require
      memory before they can make forward progress.  This happens, for instance,
      when a process must fault task->robust_list, a userspace structure, before
      detaching its memory.

      These threads also aren't guaranteed to get access to memory reserves
      unless oom killed or killed from userspace.  The oom killer won't grant
      memory reserves if other threads are also exiting other than current and
      stalling at the same point.  This prevents needlessly killing processes
      when others are already exiting.

      Instead of special casing all the possible situations between PF_EXITING
      getting set and a thread detaching its mm where it may allocate memory,
      which probably wouldn't get updated when a change is made to the exit
      path, the solution is to give all exiting threads access to memory
      reserves if they call the oom killer.  This allows them to quickly
      allocate, detach its mm, and free the memory it represents.

      Summary of Luigi's bug report:

      : He had an oom condition where threads were faulting on task->robust_list
      : and repeatedly called the oom killer but it would defer killing a thread
      : because it saw other PF_EXITING threads.  This can happen anytime we need
      : to allocate memory after setting PF_EXITING and before detaching our mm;
      : if there are other threads in the same state then the oom killer won't do
      : anything unless one of them happens to be killed from userspace.
      :
      : So instead of only deferring for PF_EXITING and !task->robust_list, it's
      : better to just give them access to memory reserves to prevent a potential
      : livelock so that any other faults that may be introduced in the future in
      : the exit path don't cause the same problem (and hopefully we don't allow
      : too many of those!).

      Signed-off-by: David Rientjes <rientjes@google.com>
      Acked-by: Minchan Kim <minchan@kernel.org>
      Tested-by: Luigi Semenzato <semenzato@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: fix race when specifying a thread as the oom origin

      test_set_oom_score_adj() and compare_swap_oom_score_adj() are used to
      specify that current should be killed first if an oom condition occurs in
      between the two calls.

      The usage is

	      short oom_score_adj = test_set_oom_score_adj(OOM_SCORE_ADJ_MAX);
	      ...
	      compare_swap_oom_score_adj(OOM_SCORE_ADJ_MAX, oom_score_adj);

      to store the thread's oom_score_adj, temporarily change it to the maximum
      score possible, and then restore the old value if it is still the same.

      This happens to still be racy, however, if the user writes
      OOM_SCORE_ADJ_MAX to /proc/pid/oom_score_adj in between the two calls.
      The compare_swap_oom_score_adj() will then incorrectly reset the old value
      prior to the write of OOM_SCORE_ADJ_MAX.

      To fix this, introduce a new oom_flags_t member in struct signal_struct
      that will be used for per-thread oom killer flags.  KSM and swapoff can
      now use a bit in this member to specify that threads should be killed
      first in oom conditions without playing around with oom_score_adj.

      This also allows the correct oom_score_adj to always be shown when reading
      /proc/pid/oom_score.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

oom: use N_MEMORY instead N_HIGH_MEMORY

      N_HIGH_MEMORY stands for the nodes that has normal or high memory.
      N_MEMORY stands for the nodes that has any memory.

      The code here need to handle with the nodes which have memory, we should
      use N_MEMORY instead.

      Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
      Acked-by: Hillf Danton <dhillf@gmail.com>
      Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

      mm, oom: cleanup pagefault oom handler

      To lock the entire system from parallel oom killing, it's possible to pass
      in a zonelist with all zones rather than using for_each_populated_zone()
      for the iteration.  This obsoletes try_set_system_oom() and
      clear_system_oom() so that they can be removed.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

      mm, oom: remove redundant sleep in pagefault oom handler

      out_of_memory() will already cause current to schedule if it has not been
      killed, so doing it again in pagefault_out_of_memory() is redundant.
      Remove it.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

memcg, oom: provide more precise dump info while memcg oom happening

      Currently when a memcg oom is happening the oom dump messages is still
      global state and provides few useful info for users.  This patch prints
      more pointed memcg page statistics for memcg-oom and take hierarchy into
      consideration:

      Based on Michal's advice, we take hierarchy into consideration: supppose
      we trigger an OOM on A's limit

	      root_memcg
		  |
		  A (use_hierachy=1)
		/ \
		B   C
		|
		D
      then the printed info will be:

	Memory cgroup stats for /A:...
	Memory cgroup stats for /A/B:...
	Memory cgroup stats for /A/C:...
	Memory cgroup stats for /A/B/D:...

      Following are samples of oom output:

      (1) Before change:

	  mal-80 invoked oom-killer:gfp_mask=0xd0, order=0, oom_score_adj=0
	  mal-80 cpuset=/ mems_allowed=0
	  Pid: 2976, comm: mal-80 Not tainted 3.7.0+ #10
	  Call Trace:
	  [<ffffffff8167fbfb>] dump_header+0x83/0x1ca
	  ..... (call trace)
	  [<ffffffff8168a818>] page_fault+0x28/0x30
				  <<<<<<<<<<<<<<<<<<<<< memcg specific information
	  Task in /A/B/D killed as a result of limit of /A
	  memory: usage 101376kB, limit 101376kB, failcnt 57
	  memory+swap: usage 101376kB, limit 101376kB, failcnt 0
	  kmem: usage 0kB, limit 9007199254740991kB, failcnt 0
				  <<<<<<<<<<<<<<<<<<<<< print per cpu pageset stat
	  Mem-Info:
	  Node 0 DMA per-cpu:
	  CPU    0: hi:    0, btch:   1 usd:   0
	  ......
	  CPU    3: hi:    0, btch:   1 usd:   0
	  Node 0 DMA32 per-cpu:
	  CPU    0: hi:  186, btch:  31 usd: 173
	  ......
	  CPU    3: hi:  186, btch:  31 usd: 130
				  <<<<<<<<<<<<<<<<<<<<< print global page state
	  active_anon:92963 inactive_anon:40777 isolated_anon:0
	  active_file:33027 inactive_file:51718 isolated_file:0
	  unevictable:0 dirty:3 writeback:0 unstable:0
	  free:729995 slab_reclaimable:6897 slab_unreclaimable:6263
	  mapped:20278 shmem:35971 pagetables:5885 bounce:0
	  free_cma:0
				  <<<<<<<<<<<<<<<<<<<<< print per zone page state
	  Node 0 DMA free:15836kB ... all_unreclaimable? no
	  lowmem_reserve[]: 0 3175 3899 3899
	  Node 0 DMA32 free:2888564kB ... all_unrelaimable? no
	  lowmem_reserve[]: 0 0 724 724
	  lowmem_reserve[]: 0 0 0 0
	  Node 0 DMA: 1*4kB (U) ... 3*4096kB (M) = 15836kB
	  Node 0 DMA32: 41*4kB (UM) ... 702*4096kB (MR) = 2888316kB
	  120710 total pagecache pages
	  0 pages in swap cache
				  <<<<<<<<<<<<<<<<<<<<< print global swap cache stat
	  Swap cache stats: add 0, delete 0, find 0/0
	  Free swap  = 499708kB
	  Total swap = 499708kB
	  1040368 pages RAM
	  58678 pages reserved
	  169065 pages shared
	  173632 pages non-shared
	  [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
	  [ 2693]     0  2693     6005     1324      17        0             0 god
	  [ 2754]     0  2754     6003     1320      16        0             0 god
	  [ 2811]     0  2811     5992     1304      18        0             0 god
	  [ 2874]     0  2874     6005     1323      18        0             0 god
	  [ 2935]     0  2935     8720     7742      21        0             0 mal-30
	  [ 2976]     0  2976    21520    17577      42        0             0 mal-80
	  Memory cgroup out of memory: Kill process 2976 (mal-80) score 665 or sacrifice child
	  Killed process 2976 (mal-80) total-vm:86080kB, anon-rss:69964kB, file-rss:344kB

      We can see that messages dumped by show_free_areas() are longsome and can
      provide so limited info for memcg that just happen oom.

      (2) After change
	  mal-80 invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
	  mal-80 cpuset=/ mems_allowed=0
	  Pid: 2704, comm: mal-80 Not tainted 3.7.0+ #10
	  Call Trace:
	  [<ffffffff8167fd0b>] dump_header+0x83/0x1d1
	  .......(call trace)
	  [<ffffffff8168a918>] page_fault+0x28/0x30
	  Task in /A/B/D killed as a result of limit of /A
				  <<<<<<<<<<<<<<<<<<<<< memcg specific information
	  memory: usage 102400kB, limit 102400kB, failcnt 140
	  memory+swap: usage 102400kB, limit 102400kB, failcnt 0
	  kmem: usage 0kB, limit 9007199254740991kB, failcnt 0
	  Memory cgroup stats for /A: cache:32KB rss:30984KB mapped_file:0KB swap:0KB inactive_anon:6912KB active_anon:24072KB inactive_file:32KB active_file:0KB unevictable:0KB
	  Memory cgroup stats for /A/B: cache:0KB rss:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
	  Memory cgroup stats for /A/C: cache:0KB rss:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
	  Memory cgroup stats for /A/B/D: cache:32KB rss:71352KB mapped_file:0KB swap:0KB inactive_anon:6656KB active_anon:64696KB inactive_file:16KB active_file:16KB unevictable:0KB
	  [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
	  [ 2260]     0  2260     6006     1325      18        0             0 god
	  [ 2383]     0  2383     6003     1319      17        0             0 god
	  [ 2503]     0  2503     6004     1321      18        0             0 god
	  [ 2622]     0  2622     6004     1321      16        0             0 god
	  [ 2695]     0  2695     8720     7741      22        0             0 mal-30
	  [ 2704]     0  2704    21520    17839      43        0             0 mal-80
	  Memory cgroup out of memory: Kill process 2704 (mal-80) score 669 or sacrifice child
	  Killed process 2704 (mal-80) total-vm:86080kB, anon-rss:71016kB, file-rss:340kB

      This version provides more pointed info for memcg in "Memory cgroup stats
      for XXX" section.

      Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
      Acked-by: Michal Hocko <mhocko@suse.cz>
      Acked-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().

      The normal expectation for ERR_PTR() is to put a negative errno into a
      pointer.  oom_kill puts the magic -1 in the result (and has since
      pre-git), which is probably clearer with an explicit cast.

      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

mm: convert mm->nr_ptes to atomic_long_t

      With split page table lock for PMD level we can't hold mm->page_table_lock
      while updating nr_ptes.

      Let's convert it to atomic_long_t to avoid races.

      Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Tested-by: Alex Thorlton <athorlton@sgi.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

      oom_kill: change oom_kill.c to use for_each_thread()

      Change oom_kill.c to use for_each_thread() rather than the racy
      while_each_thread() which can loop forever if we race with exit.

      Note also that most users were buggy even if while_each_thread() was
      fine, the task can exit even _before_ rcu_read_lock().

      Fortunately the new for_each_thread() only requires the stable
      task_struct, so this change fixes both problems.

      Signed-off-by: Oleg Nesterov <oleg@redhat.com>
      Reviewed-by: Sergey Dyasly <dserrg@gmail.com>
      Tested-by: Sergey Dyasly <dserrg@gmail.com>
      Reviewed-by: Sameer Nanda <snanda@chromium.org>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Acked-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

oom_kill: has_intersects_mems_allowed() needs rcu_read_lock()

      At least out_of_memory() calls has_intersects_mems_allowed() without
      even rcu_read_lock(), this is obviously buggy.

      Add the necessary rcu_read_lock().  This means that we can not simply
      return from the loop, we need "bool ret" and "break".

      While at it, swap the names of task_struct's (the argument and the
      local).  This cleans up the code a little bit and avoids the unnecessary
      initialization.

      Signed-off-by: Oleg Nesterov <oleg@redhat.com>
      Reviewed-by: Sergey Dyasly <dserrg@gmail.com>
      Tested-by: Sergey Dyasly <dserrg@gmail.com>
      Reviewed-by: Sameer Nanda <snanda@chromium.org>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Acked-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

oom_kill: add rcu_read_lock() into find_lock_task_mm()

      find_lock_task_mm() expects it is called under rcu or tasklist lock, but
      it seems that at least oom_unkillable_task()->task_in_mem_cgroup() and
      mem_cgroup_out_of_memory()->oom_badness() can call it lockless.

      Perhaps we could fix the callers, but this patch simply adds rcu lock
      into find_lock_task_mm().  This also allows to simplify a bit one of its
      callers, oom_kill_process().

      Signed-off-by: Oleg Nesterov <oleg@redhat.com>
      Reviewed-by: Michal Hocko <mhocko@suse.cz>
      Acked-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: prefer thread group leaders for display purposes

      When two threads have the same badness score, it's preferable to kill
      the thread group leader so that the actual process name is printed to
      the kernel log rather than the thread group name which may be shared
      amongst several processes.

      This was the behavior when select_bad_process() used to do
      for_each_process(), but it now iterates threads instead and leads to
      ambiguity.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, oom: base root bonus on current usage

      A 3% of system memory bonus is sometimes too excessive in comparison to
      other processes.

      With commit a63d83f427fb ("oom: badness heuristic rewrite"), the OOM
      killer tries to avoid killing privileged tasks by subtracting 3% of
      overall memory (system or cgroup) from their per-task consumption.  But
      as a result, all root tasks that consume less than 3% of overall memory
      are considered equal, and so it only takes 33+ privileged tasks pushing
      the system out of memory for the OOM killer to do something stupid and
      kill dhclient or other root-owned processes.  For example, on a 32G
      machine it can't tell the difference between the 1M agetty and the 10G
      fork bomb member.

      The changelog describes this 3% boost as the equivalent to the global
      overcommit limit being 3% higher for privileged tasks, but this is not
      the same as discounting 3% of overall memory from _every privileged task
      individually_ during OOM selection.

      Replace the 3% of system memory bonus with a 3% of current memory usage
      bonus.

      By giving root tasks a bonus that is proportional to their actual size,
      they remain comparable even when relatively small.  In the example
      above, the OOM killer will discount the 1M agetty's 256 badness points
      down to 179, and the 10G fork bomb's 262144 points down to 183500 points
      and make the right choice, instead of discounting both to 0 and killing
      agetty because it's first in the task list.

      Signed-off-by: David Rientjes <rientjes@google.com>
      Reported-by: Johannes Weiner <hannes@cmpxchg.org>
      Acked-by: Johannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sched: Fix hotplug vs. set_cpus_allowed_ptr()

Lai found that:

  WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124 native_smp_send_reschedule+0x2d/0x4b()
  ...
  migration_cpu_stop+0x1d/0x22

was caused by set_cpus_allowed_ptr() assuming that cpu_active_mask is
always a sub-set of cpu_online_mask.

This isn't true since 5fbd036b552f ("sched: Cleanup cpu_active madness").

So set active and online at the same time to avoid this particular
problem.

Fixes: 5fbd036b552f ("sched: Cleanup cpu_active madness")
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael wang <wangyun@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Link: http://lkml.kernel.org/r/53758B12.8060609@cn.fujitsu.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sched: Improve scalability via 'CPU buddies', which withstand random perturbations

Traversing an entire package is not only expensive, it also leads to tasks
bouncing all over a partially idle and possible quite large package.  Fix
that up by assigning a 'buddy' CPU to try to motivate.  Each buddy may try
to motivate that one other CPU, if it's busy, tough, it may then try its
SMT sibling, but that's all this optimization is allowed to cost.

Sibling cache buddies are cross-wired to prevent bouncing.

4 socket 40 core + SMT Westmere box, single 30 sec tbench runs, higher is better:

 clients     1       2       4        8       16       32       64      128
 ..........................................................................
 pre        30      41     118      645     3769     6214    12233    14312
 post      299     603    1211     2418     4697     6847    11606    14557

A nice increase in performance.

Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1339471112.7352.32.camel@marge.simpson.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sched: Reorder 'struct lb_env' members to reduce its size

Members of 'struct lb_env' are not in appropriate order to reuse compiler
added padding on 64bit architectures. In this patch we reorder those struct
members and help reduce the size of the structure from 96 bytes to 80
bytes on 64 bit architectures.

Suggested-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Prashanth Nageshappa <prashanth@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/4FE06DDE.7000403@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sched: Reset loop counters if all tasks are pinned and we need to redo load balance

While load balancing, if all tasks on the source runqueue are pinned,
we retry after excluding the corresponding source cpu. However, loop counters
env.loop and env.loop_break are not reset before retrying, which can lead
to failure in moving the tasks. In this patch we reset env.loop and
env.loop_break to their inital values before we retry.

Signed-off-by: Prashanth Nageshappa <prashanth@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/4FE06EEF.2090709@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
ARM: *squashing mainlained patches*

ARM: 7493/1: use generic unaligned.h

      This moves ARM over to the asm-generic/unaligned.h header. This has the
      benefit of better code generated especially for ARMv7 on gcc 4.7+
      compilers.

      As Arnd Bergmann, points out: The asm-generic version uses the "struct"
      version for native-endian unaligned access and the "byteshift" version
      for the opposite endianess. The current ARM version however uses the
      "byteshift" implementation for both.

      Thanks to Nicolas Pitre for the excellent analysis:

      Test case:

      int foo (int *x) { return get_unaligned(x); }
      long long bar (long long *x) { return get_unaligned(x); }

      With the current ARM version:

      foo:
	      ldrb	r3, [r0, #2]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
	      ldrb	r1, [r0, #1]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
	      ldrb	r2, [r0, #0]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
	      mov	r3, r3, asl #16	@ tmp154, MEM[(const u8 *)x_1(D) + 2B],
	      ldrb	r0, [r0, #3]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
	      orr	r3, r3, r1, asl #8	@, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],
	      orr	r3, r3, r2	@ tmp157, tmp155, MEM[(const u8 *)x_1(D)]
	      orr	r0, r3, r0, asl #24	@,, tmp157, MEM[(const u8 *)x_1(D) + 3B],
	      bx	lr	@

      bar:
	      stmfd	sp!, {r4, r5, r6, r7}	@,
	      mov	r2, #0	@ tmp184,
	      ldrb	r5, [r0, #6]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]
	      ldrb	r4, [r0, #5]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]
	      ldrb	ip, [r0, #2]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
	      ldrb	r1, [r0, #4]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]
	      mov	r5, r5, asl #16	@ tmp175, MEM[(const u8 *)x_1(D) + 6B],
	      ldrb	r7, [r0, #1]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
	      orr	r5, r5, r4, asl #8	@, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],
	      ldrb	r6, [r0, #7]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]
	      orr	r5, r5, r1	@ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]
	      ldrb	r4, [r0, #0]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
	      mov	ip, ip, asl #16	@ tmp188, MEM[(const u8 *)x_1(D) + 2B],
	      ldrb	r1, [r0, #3]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
	      orr	ip, ip, r7, asl #8	@, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],
	      orr	r3, r5, r6, asl #24	@,, tmp178, MEM[(const u8 *)x_1(D) + 7B],
	      orr	ip, ip, r4	@ tmp191, tmp189, MEM[(const u8 *)x_1(D)]
	      orr	ip, ip, r1, asl #24	@, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],
	      mov	r1, r3	@,
	      orr	r0, r2, ip	@ tmp171, tmp184, tmp194
	      ldmfd	sp!, {r4, r5, r6, r7}
	      bx	lr

      In both cases the code is slightly suboptimal.  One may wonder why
      wasting r2 with the constant 0 in the second case for example.  And all
      the mov's could be folded in subsequent orr's, etc.

      Now with the asm-generic version:

      foo:
	      ldr	r0, [r0, #0]	@ unaligned	@,* x
	      bx	lr	@

      bar:
	      mov	r3, r0	@ x, x
	      ldr	r0, [r0, #0]	@ unaligned	@,* x
	      ldr	r1, [r3, #4]	@ unaligned	@,
	      bx	lr	@

      This is way better of course, but only because this was compiled for
      ARMv7. In this case the compiler knows that the hardware can do
      unaligned word access.  This isn't that obvious for foo(), but if we
      remove the get_unaligned() from bar as follows:

      long long bar (long long *x) {return *x; }

      then the resulting code is:

      bar:
	      ldmia	r0, {r0, r1}	@ x,,
	      bx	lr	@

      So this proves that the presumed aligned vs unaligned cases does have
      influence on the instructions the compiler may use and that the above
      unaligned code results are not just an accident.

      Still... this isn't fully conclusive without at least looking at the
      resulting assembly fron a pre ARMv6 compilation.  Let's see with an
      ARMv5 target:

      foo:
	      ldrb	r3, [r0, #0]	@ zero_extendqisi2	@ tmp139,* x
	      ldrb	r1, [r0, #1]	@ zero_extendqisi2	@ tmp140,
	      ldrb	r2, [r0, #2]	@ zero_extendqisi2	@ tmp143,
	      ldrb	r0, [r0, #3]	@ zero_extendqisi2	@ tmp146,
	      orr	r3, r3, r1, asl #8	@, tmp142, tmp139, tmp140,
	      orr	r3, r3, r2, asl #16	@, tmp145, tmp142, tmp143,
	      orr	r0, r3, r0, asl #24	@,, tmp145, tmp146,
	      bx	lr	@

      bar:
	      stmfd	sp!, {r4, r5, r6, r7}	@,
	      ldrb	r2, [r0, #0]	@ zero_extendqisi2	@ tmp139,* x
	      ldrb	r7, [r0, #1]	@ zero_extendqisi2	@ tmp140,
	      ldrb	r3, [r0, #4]	@ zero_extendqisi2	@ tmp149,
	      ldrb	r6, [r0, #5]	@ zero_extendqisi2	@ tmp150,
	      ldrb	r5, [r0, #2]	@ zero_extendqisi2	@ tmp143,
	      ldrb	r4, [r0, #6]	@ zero_extendqisi2	@ tmp153,
	      ldrb	r1, [r0, #7]	@ zero_extendqisi2	@ tmp156,
	      ldrb	ip, [r0, #3]	@ zero_extendqisi2	@ tmp146,
	      orr	r2, r2, r7, asl #8	@, tmp142, tmp139, tmp140,
	      orr	r3, r3, r6, asl #8	@, tmp152, tmp149, tmp150,
	      orr	r2, r2, r5, asl #16	@, tmp145, tmp142, tmp143,
	      orr	r3, r3, r4, asl #16	@, tmp155, tmp152, tmp153,
	      orr	r0, r2, ip, asl #24	@,, tmp145, tmp146,
	      orr	r1, r3, r1, asl #24	@,, tmp155, tmp156,
	      ldmfd	sp!, {r4, r5, r6, r7}
	      bx	lr

      Compared to the initial results, this is really nicely optimized and I
      couldn't do much better if I were to hand code it myself.

      Signed-off-by: Rob Herring <rob.herring@calxeda.com>
      Reviewed-by: Nicolas Pitre <nico@linaro.org>
      Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7822/1: add workaround for ambiguous C99 stdint.h types

      The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
      unambiguous on ARM as you would expect. For the types below, there is a
      difference on ARM between GCC built for bare metal ARM, GCC built for glibc
      and the kernel itself, which results in build errors if you try to build with
      -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
      in order to use NEON intrinsics)

      As the typedefs for these types in 'stdint.h' are based on builtin defines
      supplied by GCC, we can tweak these to align with the kernel's idea of those
      types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
      source file (provided that -ffreestanding is used).

			int32_t         uint32_t               uintptr_t
      bare metal GCC     long            unsigned long          unsigned int
      glibc GCC          int             unsigned int           unsigned int
      kernel             int             unsigned int           unsigned long

      Acked by: Dave Martin <dave.martin@arm.com>

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Acked-by: Mikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7491/1: use generic version of identical asm headers

      Inspired by the AArgh64 claim that it should be separate from ARM and one
      reason was being able to use more asm-generic headers. Doing a diff of
      arch/arm/include/asm and include/asm-generic there are numerous asm
      headers which are functionally identical to their asm-generic counterparts.
      Delete the ARM version and use the generic ones.

      Signed-off-by: Rob Herring <rob.herring@calxeda.com>
      Reviewed-by: Nicolas Pitre <nico@linaro.org>
      Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7494/1: use generic termios.h

      As pointed out by Arnd Bergmann, this fixes a couple of issues but will
      increase code size:

      The original macro user_termio_to_kernel_termios was not endian safe. It
      used an unsigned short ptr to access the low bits in a 32-bit word.

      Both user_termio_to_kernel_termios and kernel_termios_to_user_termio are
      missing error checking on put_user/get_user and copy_to/from_user.

      Signed-off-by: Rob Herring <rob.herring@calxeda.com>
      Reviewed-by: Nicolas Pitre <nico@linaro.org>
      Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7587/1: implement optimized percpu variable access

      Use the previously unused TPIDRPRW register to store percpu offsets.
      TPIDRPRW is only accessible in PL1, so it can only be used in the kernel.

      This replaces 2 loads with a mrc instruction for each percpu variable
      access. With hackbench, the performance improvement is 1.4% on Cortex-A9
      (highbank). Taking an average of 30 runs of "hackbench -l 1000" yields:

      Before: 6.2191
      After: 6.1348

      Will Deacon reported similar delta on v6 with 11MPCore.

      The asm "memory clobber" are needed here to ensure the percpu offset
      gets reloaded. Testing by Will found that this would not happen in
      __schedule() which is a bit of a special case as preemption is disabled
      but the execution can move cores.

      Signed-off-by: Rob Herring <rob.herring@calxeda.com>
      Acked-by: Will Deacon <will.deacon@arm.com>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: bpf_jit: add XOR operation

      Add XOR instruction fo BPF machine. Needed for computing packet hashes.

      Signed-off-by: Jiri Pirko <jpirko@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>

ARM: 7421/1: bpf_jit: BPF_S_ANC_ALU_XOR_X support

      JIT support for the XOR operation introduced by the commit
      ffe06c17afbb.

      Signed-off-by: Mircea Gherzan <mgherzan@gmail.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: net: bpf_jit_32: add XOR instruction for BPF JIT

      This patch is a follow-up for patch "filter: add XOR instruction for use
      with X/K" that implements BPF ARM JIT parts for the BPF XOR operation.

      Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
      Cc: Mircea Gherzan <mgherzan@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: Mircea Gherzan <mgherzan@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>

ARM: net: bpf_jit_32: add VLAN instructions for BPF JIT

      This patch is a follow-up for patch "net: filter: add vlan tag access"
      to support the new VLAN_TAG/VLAN_TAG_PRESENT accessors in BPF JIT.

      Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
      Cc: Mircea Gherzan <mgherzan@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: Mircea Gherzan <mgherzan@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>

ARM: 7597/1: net: bpf_jit_32: fix kzalloc gfp/size mismatch.

      Official prototype for kzalloc is:

      void *kzalloc(size_t, gfp_t);

      The ARM bpf_jit code was having the assumption that it was:

      void *kzalloc(gfp_t, size);

      This was resulting the use of some random GFP flags depending on the
      size requested and some random overflows once the really needed size
      was more than the value of GFP_KERNEL.

      This bug was present since the original inclusion of bpf_jit for ARM
      (ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters).

      Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7598/1: net: bpf_jit_32: fix sp-relative load/stores offsets.

      The offset must be multiplied by 4 to be sure to access the correct
      32bit word in the stack scratch space.

      For instance, a store at scratch memory cell #1 was generating the
      following:

      st	r4, [sp, #1]

      While the correct code for this is:

      st	r4, [sp, #4]

      To reproduce the bug (assuming your system has a NIC with the mac
      address 52:54:00:12:34:56):

      echo 0 > /proc/sys/net/core/bpf_jit_enable
      tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \
	      == -0x3AA" # this will capture packets as expected

      echo 1 > /proc/sys/net/core/bpf_jit_enable
      tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \
	      == -0x3AA" # this will not.

      This bug was present since the original inclusion of bpf_jit for ARM
      (ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters).

      Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: net: bpf_jit: fix emit_swap16() for non ARMv6+.

      The original code was generating an lsl instructions using the value
      of ARM_R8 (skb_headlen, possibly uninitialized if no skb_headlen
      access was required) as a shift amount.

      Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
      Acked-by: Mircea Gherzan <mgherzan@gmail.com>
      Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: David S. Miller <davem@davemloft.net>

ARM:net: an issue for k which is u32, never < 0

	k is u32 which never < 0, need type cast, or cause issue.

      Signed-off-by: Chen Gang <gang.chen@asianux.com>
      Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: Mircea Gherzan <mgherzan@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>

filter: bpf_jit_comp: refactor and unify BPF JIT image dump output

      If bpf_jit_enable > 1, then we dump the emitted JIT compiled image
      after creation. Currently, only SPARC and PowerPC has similar output
      as in the reference implementation on x86_64. Make a small helper
      function in order to reduce duplicated code and make the dump output
      uniform across architectures x86_64, SPARC, PPC, ARM (e.g. on ARM
      flen, pass and proglen are currently not shown, but would be
      interesting to know as well), also for future BPF JIT implementations
      on other archs.

      Cc: Mircea Gherzan <mgherzan@gmail.com>
      Cc: Matt Evans <matt@ozlabs.org>
      Cc: Eric Dumazet <eric.dumazet@google.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>

arm: bpf_jit: can call module_free() from any context

      Follow-up on module_free()/vfree() that takes care of the rest, so no
      longer this workaround with work_struct needed.

      Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Mircea Gherzan <mgherzan@gmail.com>
      Signed-off-by: David S. Miller <davem@davemloft.net>

      # This is the 11th commit message:

      ARM: net: fix arm instruction endian-ness in bpf_jit_32.c

      Use <asm/opcodes.h> to correctly transform instruction byte ordering
      into in-memory ordering.

      Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
      Reviewed-by: Dave Martin <Dave.Martin@arm.com>

ARM: 7590/1: /proc/interrupts: limit the display of IPIs to online CPUs only

This is what is done for the regular interrupts in kernel/irqs/proc.c
already, before calling arch_show_interrupts().  Not doing so for the
IPIs causes the column headers not to match with the content whenever
some CPUs are offline.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>