Makefile: arch/arm/boot/compressed: *squashing updates from ARM-software*
mm/page-writeback.c: *squashing updates*

mm/page-writeback.c: fix dirty_balance_reserve subtraction from dirtyable memory

      commit a804552b9a15c931cfc2a92a2e0aed1add8b580a upstream.

      Tejun reported stuttering and latency spikes on a system where random
      tasks would enter direct reclaim and get stuck on dirty pages.  Around
      50% of memory was occupied by tmpfs backed by an SSD, and another disk
      (rotating) was reading and writing at max speed to shrink a partition.

      : The problem was pretty ridiculous.  It's a 8gig machine w/ one ssd and 10k
      : rpm harddrive and I could reliably reproduce constant stuttering every
      : several seconds for as long as buffered IO was going on on the hard drive
      : either with tmpfs occupying somewhere above 4gig or a test program which
      : allocates about the same amount of anon memory.  Although swap usage was
      : zero, turning off swap also made the problem go away too.
      :
      : The trigger conditions seem quite plausible - high anon memory usage w/
      : heavy buffered IO and swap configured - and it's highly likely that this
      : is happening in the wild too.  (this can happen with copying large files
      : to usb sticks too, right?)

      This patch (of 2):

      The dirty_balance_reserve is an approximation of the fraction of free
      pages that the page allocator does not make available for page cache
      allocations.  As a result, it has to be taken into account when
      calculating the amount of "dirtyable memory", the baseline to which
      dirty_background_ratio and dirty_ratio are applied.

      However, currently the reserve is subtracted from the sum of free and
      reclaimable pages, which is non-sensical and leads to erroneous results
      when the system is dominated by unreclaimable pages and the
      dirty_balance_reserve is bigger than free+reclaimable.  In that case, at
      least the already allocated cache should be considered dirtyable.

      Fix the calculation by subtracting the reserve from the amount of free
      pages, then adding the reclaimable pages on top.

      [akpm@linux-foundation.org: fix CONFIG_HIGHMEM build]
      Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
      Reported-by: Tejun Heo <tj@kernel.org>
      Tested-by: Tejun Heo <tj@kernel.org>
      Reviewed-by: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Wu Fengguang <fengguang.wu@intel.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>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm: page-writeback.c: local functions should not be exposed globally

      The function global_dirtyable_memory is only referenced in this file and
      should be marked static to prevent it from being exposed globally.

      This quiets the sparse warning:

      warning: symbol 'global_dirtyable_memory' was not declared. Should it be static?

      Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>

writeback: initialize global_dirty_limit

      This prevents global_dirty_limit from remaining 0 (the initial value)
      for long time, since it's only updated in update_dirty_limit() when
      above the dirty freerun area.

      It will avoid unexpected consequences when some random code use it as a
      convenient approximation of the global dirty threshold.

      Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>

writeback: Fix some comment errors

      Signed-off-by: Wanpeng Li <liwp@linux.vnet.ibm.com>
      Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>

CPU hotplug, writeback: Don't call writeback_set_ratelimit() too often during hotplug

      The CPU hotplug callback related to writeback calls writeback_set_ratelimit()
      during every state change in the hotplug sequence. This is unnecessary
      since num_online_cpus() changes only once during the entire hotplug operation.

      So invoke the function only once per hotplug, thereby avoiding the
      unnecessary repetition of those costly calculations.

      Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>

writeback: remove nr_pages_dirtied arg from balance_dirty_pages_ratelimited_nr()

      There is no reason to pass the nr_pages_dirtied argument, because
      nr_pages_dirtied value from the caller is unused in
      balance_dirty_pages_ratelimited_nr().

      Signed-off-by: Namjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: Vivek Trivedi <vtrivedi018@gmail.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Negative (setpoint-dirty) in bdi_position_ratio()

      In bdi_position_ratio(), get difference (setpoint-dirty) right even when
      negative. Both setpoint and dirty are unsigned long, the difference was
      zero-padded thus wrongly sign-extended to s64. This issue affects all
      32-bit architectures, does not affect 64-bit architectures where long
      and s64 are equivalent.

      In this function, dirty is between freerun and limit, the pseudo-float x
      is between [-1,1], expected to be negative about half the time. With
      zero-padding, instead of a small negative x we obtained a large positive
      one so bdi_position_ratio() returned garbage.

      Casting the difference to s64 also prevents overflow with left-shift;
      though normally these numbers are small and I never observed a 32-bit
      overflow there.

      (This patch does not solve the PAE OOM issue.)

      Paul Szabo   psz@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
      School of Mathematics and Statistics   University of Sydney    Australia

      Reviewed-by: Jan Kara <jack@suse.cz>
      Reported-by: Paul Szabo <psz@maths.usyd.edu.au>
      Reference: http://bugs.debian.org/695182
      Signed-off-by: Paul Szabo <psz@maths.usyd.edu.au>
      Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
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>
*enabling ccache to speed up re-compilation*
drivers: msm_nand: *silence GCC warnings*

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
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
fs: ext4: reverting huawei specific changes
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: *syncing with 3.4 mainline*

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>
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>
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>
cpufreq: ondemand: *squashing updates*

synced with korg/linux-3.4.y mainline
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>
msm: cpufreq: *squashing updates*

- cherry-picked updates from CodeAurora
- small bugfix (fixed and hotplug race condition)
*squashing hot-plug related updates*

msm: pm2: Raise SPI interrupt instread of SGI to non boot CPUs

      Once APPS comes out of PC and mpdecision want to bring the non-boot
      cpus to online, first CORE0 raises the SPI interrupt(MPCORE) to bring
      the cores(1/2/3) online. While bringing the cores online, CORE0 raises
      the SPI interrupt instead of SGI. Because once APPS does a PC QGIC
      looses its state and none of the non-boot cpus are not capable of
      receiving the SGI interrupt until cores configure the QGIC PPIs&SGIs
      by themselves.

      Change-Id: Ic4aedeffbcd3fa2f0aa15e2e8ed7e25a03468f87
      Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>

msm: platsmp-8625: modify pen_release variable to volatile

      Since pen_release is a shared variable between cpus. By marking it
      as volatile, compiler won't cache that variable into registers and
      won't optimize the code which access pen_release variable.

      Change-Id: Ib5b7aa5932b35d64d05f9e4a4672df2bb9207c59
      Signed-off-by: tirupathireddy <tirupath@codeaurora.org>

pm2 update

msm: hotplug: Change the pen variable in one place

      Other WFI based hotplug implementations set the pen variable to
      -1 in C code and do the appropriate flushing operations in one
      location. They also don't try to invalidate the cache on a
      spurious wakeup and report how many spurious wakeups there were.
      Let's do the same in our code so that we can remove our
      dependence on the dmac_{inv,flush}_range() functions (which are
      no longer upstream) and easily report spurious wakeups to the
      kernel logs.

      This does delay the time we set the pen back to its default
      value, but that doesn't actually matter because generic ARM
      hotplug code already waits for a completion before continuing.

      Change-Id: Ic36fbf744fe8abeda20ad9859a207b5e37c5e63c
      Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>

msm: hotplug: wait for hotplug completion event from secondary core

      Primary core has to wait for hotplug completion event from secondary
      core to avoid race between ongoing hotplug and already queued online
      event. This also prevent CPU_DEAD notifiers from executing before the
      SPM has completed the collapse of the CPU. CPU DEAD notifiers executing
      early have been attributed to MDD hardware block for the CPU being
      turned off prematurely, resulting in crashes.

      The patch also adds support for probing with device tree for 8974
      targets.

      Change-Id: I8c155324adfee35825181bbf7b28a52b87ca2938
      CRs-fixed: 438314,457541
      Signed-off-by: Anji Jonnala <anjir@codeaurora.org>

msm: hotplug: remove code related to cpu_killed

      Earlier the completion event cpu_killed was used to synchronize
      notify to hot plug framework that the CPU is dead. But now it is
      replaced with another completion event cpu_died and it is placed
      in the hotplug framework itself. So there is no need for a
      platform to implement a completion event.

      But in msm platform driver the completion event related code
      was not removed with the changes in hotplug framework. This
      patch removes the unused code.

      Change-Id: I4418e5e397821e39a7b6a6efa997c4a866e9b46b
      Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>

msm: hotplug: Block hotplug removal of CPU0

      Hotplug removal of CPU0 is not currently supported. Attempts to
      remove it may result in undefined behaviour. Explicitly block
      any such attempts before other hotplug notifiers get the chance
      to run by setting the notifier priority to INT_MAX.

      Change-Id: I9e1f5b4a0db554295a097220417f2bdf4c690f5f
      Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
Makefile: trying some GCC flags
cpufreq
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>