*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*

cpufreq: ondemand: *reverting huawei specific changes*

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: Disable freq sync feature in store_powersave_bias

      Turn off frequency synchronization of CPUs on thread migrations
      when powersave bias is enabled. This is done to prevent re-arming
      of the dbs timer work (which is cancelled by store_powersave_bias)
      by the sync_thread.

      Change-Id: I165dd591845c1d66d01a14e8dfc44c767c677b0d
      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: 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 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: 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: Change the calculation of target frequency

      *backported for kernel 3.4.y*

      The ondemand governor calculates load in terms of frequency and
      increases it only if load_freq is greater than up_threshold
      multiplied by the current or average frequency.  This appears to
      produce oscillations of frequency between min and max because,
      for example, a relatively small load can easily saturate minimum
      frequency and lead the CPU to the max.  Then, it will decrease
      back to the min due to small load_freq.

      Change the calculation method of load and target frequency on the
      basis of the following two observations:

      - Load computation should not depend on the current or average
	measured frequency.  For example, absolute load of 80% at 100MHz
	is not necessarily equivalent to 8% at 1000MHz in the next
	sampling interval.

      - It should be possible to increase the target frequency to any
	value present in the frequency table proportional to the absolute
	load, rather than to the max only, so that:

	Target frequency = C * load

	where we take C = policy->cpuinfo.max_freq / 100.

      Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait.
      Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an
      increase ~1.5% in performance. cpufreq_stats (time_in_state) shows
      that middle frequencies are used more, with this patch.  Highest
      and lowest frequencies were used less by ~9%.

      [rjw: We have run multiple other tests on kernels with this
      change applied and in the vast majority of cases it turns out
      that the resulting performance improvement also leads to reduced
      consumption of energy.  The change is additionally justified by
      the overall simplification of the code in question.]

      Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
      Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: moddingg33k <moddingg33k@t-online.de>

cpufreq / ondemand: update frequency when limits are relaxed

      Reevaluate CPU load and update frequency immediately whenever limits
      are changed. Currently ondemand doesn't do that when limits are
      relaxed, wasting power on systems with relatively low sampling rate.

      Signed-off-by: Michal Pecio <mpecio@nvidia.com>
      Reviewed-by: Thomas Renninger <trenn@suse.de>
      Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
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 from CodeAurora
- extended by myself (fixed and hotplug race condition)
workqueue: *syncing with korg/linux-3.7.y*

(sry...too many commits)
timer: *squashing updates*

timer: Fix mod_timer_pinned() header comment

      The mod_timer_pinned() header comment states that it prevents timers
      from being migrated to a different CPU.  This is not the case, instead,
      it ensures that the timer is posted to the current CPU, but does nothing
      to prevent CPU-hotplug operations from migrating the timer.

      This commit therefore brings the comment header into alignment with
      reality.

      Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
      Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: Steven Rostedt <rostedt@goodmis.org>

userns: Convert setting and getting uid and gid system calls to use kuid and kgid

      Convert setregid, setgid, setreuid, setuid,
      setresuid, getresuid, setresgid, getresgid, setfsuid, setfsgid,
      getuid, geteuid, getgid, getegid,
      waitpid, waitid, wait4.

      Convert userspace uids and gids into kuids and kgids before
      being placed on struct cred.  Convert struct cred kuids and
      kgids into userspace uids and gids when returning them.

      Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

lockdep: fix oops in processing workqueue

      Under memory load, on x86_64, with lockdep enabled, the workqueue's
      process_one_work() has been seen to oops in __lock_acquire(), barfing
      on a 0xffffffff00000000 pointer in the lockdep_map's class_cache[].

      Because it's permissible to free a work_struct from its callout function,
      the map used is an onstack copy of the map given in the work_struct: and
      that copy is made without any locking.

      Surprisingly, gcc (4.5.1 in Hugh's case) uses "rep movsl" rather than
      "rep movsq" for that structure copy: which might race with a workqueue
      user's wait_on_work() doing lock_map_acquire() on the source of the
      copy, putting a pointer into the class_cache[], but only in time for
      the top half of that pointer to be copied to the destination map.

      Boom when process_one_work() subsequently does lock_map_acquire()
      on its onstack copy of the lockdep_map.

      Fix this, and a similar instance in call_timer_fn(), with a
      lockdep_copy_map() function which additionally NULLs the class_cache[].

      Note: this oops was actually seen on 3.4-next, where flush_work() newly
      does the racing lock_map_acquire(); but Tejun points out that 3.4 and
      earlier are already vulnerable to the same through wait_on_work().

      * Patch orginally from Peter.  Hugh modified it a bit and wrote the
	description.

      Signed-off-by: Peter Zijlstra <peterz@infradead.org>
      Reported-by: Hugh Dickins <hughd@google.com>
      LKML-Reference: <alpine.LSU.2.00.1205070951170.1544@eggly.anvils>
      Signed-off-by: Tejun Heo <tj@kernel.org>

trace: Remove unused workqueue tracer

      This tracer was temporarily removed in 6416669 (workqueue:
      temporarily remove workqueue tracing, 2010-06-29) but never
      reinstated after concurrency managed workqueues were completed.
      For almost two years it hasn't been compilable so it seems nobody
      is using it. Delete it.

      Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
      Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: Tejun Heo <tj@kernel.org>

timers: Create detach_if_pending() and use it

      Most callers of detach_timer() have the same pattern around
      them. Check whether the timer is pending and eventually updating
      base->next_timer.

      Create detach_if_pending() and replace the duplicated code.

      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/20120525214819.131246037@linutronix.de

timers: Consolidate base->next_timer update

      Another bunch of mindlessly copied code. All callers of
      internal_add_timer() except the recascading code updates
      base->next_timer.

      Move this into internal_add_timer() and let the cascading code call
      __internal_add_timer().

      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/20120525214819.189946224@linutronix.de

timers: Add accounting of non deferrable timers

      The code in get_next_timer_interrupt() is suboptimal as it has to run
      through the cascade to find the next expiring timer. On a completely
      idle core we should only do that when there is an active timer
      enqueued and base->next_timer does not give us a fast answer.

      Add accounting of the active timers to the now consolidated
      attach/detach code. I deliberately avoided sanity checks because the
      code is fully symetric and any fiddling with timers w/o using the API
      functions will lead to cute explosions anyway. ulong is big enough
      even on 32bit and if we really run into the situation to have more
      than 1<<32 timers enqueued there, then we are definitely not in a
      state to go idle and run through that code.

      This allows us to fix another shortcoming of get_next_timer_interrupt().

      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Gilad Ben-Yossef <gilad@benyossef.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/20120525214819.236377028@linutronix.de

timers: Improve get_next_timer_interrupt()

      Gilad reported at

      http://lkml.kernel.org/r/1336056962-10465-2-git-send-email-gilad@benyossef.com

      "Current timer code fails to correctly return a value meaning that
      there is no future timer event, with the result that the timer keeps
      getting re-armed in HZ one shot mode even when we could turn it off,
      generating unneeded interrupts.

      What is happening is that when __next_timer_interrupt() wishes
      to return a value that signifies "there is no future timer
      event", it returns (base->timer_jiffies + NEXT_TIMER_MAX_DELTA).

      However, the code in tick_nohz_stop_sched_tick(), which called
      __next_timer_interrupt() via get_next_timer_interrupt(),
      compares the return value to (last_jiffies + NEXT_TIMER_MAX_DELTA)
      to see if the timer needs to be re-armed.

      base->timer_jiffies != last_jiffies and so tick_nohz_stop_sched_tick()
      interperts the return value as indication that there is a distant
      future event 12 days from now and programs the timer to fire next
      after KTIME_MAX nsecs instead of avoiding to arm it. This ends up
      causing a needless interrupt once every KTIME_MAX nsecs."

      Fix this by using the new active timer accounting. This avoids scans
      when no active timer is enqueued completely, so we don't have to rely
      on base->timer_next and base->timer_jiffies anymore.

      Reported-by: Gilad Ben-Yossef <gilad@benyossef.com>
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/20120525214819.317535385@linutronix.de

timer: Generalize timer->base flags handling

      To prepare for addition of another flag, generalize timer->base flags
      handling.

      * Rename from TBASE_*_FLAG to TIMER_* and make them LU constants.

      * Define and use TIMER_FLAG_MASK for flags masking so that multiple
	flags can be handled correctly.

      * Don't dereference timer->base directly even if
	!tbase_get_deferrable().  All two such places are already passed in
	@base, so use it instead.

      * Make sure tvec_base's alignment is large enough for timer->base
	flags using BUILD_BUG_ON().

      Signed-off-by: Tejun Heo <tj@kernel.org>
      Cc: torvalds@linux-foundation.org
      Cc: peterz@infradead.org
      Link: http://lkml.kernel.org/r/1344449428-24962-2-git-send-email-tj@kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

timer: Clean up timer initializers

      Over time, timer initializers became messy with unnecessarily
      duplicated code which are inconsistently spread across timer.h and
      timer.c.

      This patch cleans up timer initializers.

      * timer.c::__init_timer() is renamed to do_init_timer().

      * __TIMER_INITIALIZER() added.  It takes @flags and all initializers
	are wrappers around it.

      * init_timer[_on_stack]_key() now take @flags.

      * __init_timer[_on_stack]() added.  They take @flags and all init
	macros are wrappers around them.

      * __setup_timer[_on_stack]() added.  It uses __init_timer() and takes
	@flags.  All setup macros are wrappers around the two.

      Note that this patch doesn't add missing init/setup combinations -
      e.g. init_timer_deferrable_on_stack().  Adding missing ones is
      trivial.

      Signed-off-by: Tejun Heo <tj@kernel.org>
      Cc: torvalds@linux-foundation.org
      Cc: peterz@infradead.org
      Link: http://lkml.kernel.org/r/1344449428-24962-4-git-send-email-tj@kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

timer: Implement TIMER_IRQSAFE

      Timer internals are protected with irq-safe locks but timer execution
      isn't, so a timer being dequeued for execution and its execution
      aren't atomic against IRQs.  This makes it impossible to wait for its
      completion from IRQ handlers and difficult to shoot down a timer from
      IRQ handlers.

      This issue caused some issues for delayed_work interface.  Because
      there's no way to reliably shoot down delayed_work->timer from IRQ
      handlers, __cancel_delayed_work() can't share the logic to steal the
      target delayed_work with cancel_delayed_work_sync(), and can only
      steal delayed_works which are on queued on timer.  Similarly, the
      pending mod_delayed_work() can't be used from IRQ handlers.

      This patch adds a new timer flag TIMER_IRQSAFE, which makes the timer
      to be executed without enabling IRQ after dequeueing such that its
      dequeueing and execution are atomic against IRQ handlers.

      This makes it safe to wait for the timer's completion from IRQ
      handlers, for example, using del_timer_sync().  It can never be
      executing on the local CPU and if executing on other CPUs it won't be
      interrupted until done.

      This will enable simplifying delayed_work cancel/mod interface.

      Signed-off-by: Tejun Heo <tj@kernel.org>
      Cc: torvalds@linux-foundation.org
      Cc: peterz@infradead.org
      Link: http://lkml.kernel.org/r/1344449428-24962-5-git-send-email-tj@kernel.org
      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace

Pull user namespace enhancements from Eric Biederman:
 "This is a course correction for the user namespace, so that we can
  reach an inexpensive, maintainable, and reasonably complete
  implementation.

  Highlights:
   - Config guards make it impossible to enable the user namespace and
     code that has not been converted to be user namespace safe.

   - Use of the new kuid_t type ensures the if you somehow get past the
     config guards the kernel will encounter type errors if you enable
     user namespaces and attempt to compile in code whose permission
     checks have not been updated to be user namespace safe.

   - All uids from child user namespaces are mapped into the initial
     user namespace before they are processed.  Removing the need to add
     an additional check to see if the user namespace of the compared
     uids remains the same.

   - With the user namespaces compiled out the performance is as good or
     better than it is today.

   - For most operations absolutely nothing changes performance or
     operationally with the user namespace enabled.

   - The worst case performance I could come up with was timing 1
     billion cache cold stat operations with the user namespace code
     enabled.  This went from 156s to 164s on my laptop (or 156ns to
     164ns per stat operation).

   - (uid_t)-1 and (gid_t)-1 are reserved as an internal error value.
     Most uid/gid setting system calls treat these value specially
     anyway so attempting to use -1 as a uid would likely cause
     entertaining failures in userspace.

   - If setuid is called with a uid that can not be mapped setuid fails.
     I have looked at sendmail, login, ssh and every other program I
     could think of that would call setuid and they all check for and
     handle the case where setuid fails.

   - If stat or a similar system call is called from a context in which
     we can not map a uid we lie and return overflowuid.  The LFS
     experience suggests not lying and returning an error code might be
     better, but the historical precedent with uids is different and I
     can not think of anything that would break by lying about a uid we
     can't map.

   - Capabilities are localized to the current user namespace making it
     safe to give the initial user in a user namespace all capabilities.

  My git tree covers all of the modifications needed to convert the core
  kernel and enough changes to make a system bootable to runlevel 1."

Fix up trivial conflicts due to nearby independent changes in fs/stat.c

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (46 commits)
  userns:  Silence silly gcc warning.
  cred: use correct cred accessor with regards to rcu read lock
  userns: Convert the move_pages, and migrate_pages permission checks to use uid_eq
  userns: Convert cgroup permission checks to use uid_eq
  userns: Convert tmpfs to use kuid and kgid where appropriate
  userns: Convert sysfs to use kgid/kuid where appropriate
  userns: Convert sysctl permission checks to use kuid and kgids.
  userns: Convert proc to use kuid/kgid where appropriate
  userns: Convert ext4 to user kuid/kgid where appropriate
  userns: Convert ext3 to use kuid/kgid where appropriate
  userns: Convert ext2 to use kuid/kgid where appropriate.
  userns: Convert devpts to use kuid/kgid where appropriate
  userns: Convert binary formats to use kuid/kgid where appropriate
  userns: Add negative depends on entries to avoid building code that is userns unsafe
  userns: signal remove unnecessary map_cred_ns
  userns: Teach inode_capable to understand inodes whose uids map to other namespaces.
  userns: Fail exec for suid and sgid binaries with ids outside our user namespace.
  userns: Convert stat to return values mapped from kuids and kgids
  userns: Convert user specfied uids and gids in chown into kuids and kgid
  userns: Use uid_eq gid_eq helpers when comparing kuids and kgids in the vfs