lib/checksum.c: optimize do_csum a bit

Reduce the number of variables modified by the loop in do_csum() by 1,
which seems like a good idea.  On Nios II (a RISC CPU with 3-operand
instruction set) it reduces the loop from 7 to 6 instructions, including
the conditional branch.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
cpufreq: ondemand: use system_wq instead of dedicated workqueues

With cmwq, there's no reason for cpufreq drivers to use separate
workqueues.  Remove the dedicated workqueues from cpufreq_ondemand and use system_wq instead.  The work items are
already sync canceled on stop, so it's already guaranteed that no work
is running on module exit.
fs: mark_inode_dirty barrier fix

    Filesystems appear to be using ->dirty_inode, expecting that the dirtying
    operating is done and visible to all CPUs (eg. setting private inode dirty
    bits, without any barriers themselves). So release the dirty "critical
    section" with a barrier before calling ->dirty_inode.

    Cost is not significantly changed, because we're just moving the barrier.
    Those filesystems that do use ->dirty_inode should have to care slightly
    less about barriers, which is a good thing.

    Signed-off-by: Nick Piggin <npiggin@kernel.dk>
PM / Runtime: Use alloc_workqueue() for creating the PM workqueue

    Although we need the PM workqueue to be freezable, we don't need it
    to be singlethread.  Also, the number of concurrent work items
    running on a single CPU need not be constrained.  For these reasons
    use alloc_workqueue() directly, with suitable arguments, instead of
    create_freezeable_workqueue(), to create the runtime PM workqueue.

    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Tejun Heo <tj@kernel.org>
Freezer: Fix a race during freezing of TASK_STOPPED tasks

    After calling freeze_task(), try_to_freeze_tasks() see whether the
    task is stopped or traced and if so, considers it to be frozen;
    however, nothing guarantees that either the task being frozen sees
    TIF_FREEZE or the freezer sees TASK_STOPPED -> TASK_RUNNING
    transition.  The task being frozen may wake up and not see TIF_FREEZE
    while the freezer fails to notice the transition and believes the task
    is still stopped.

    This patch fixes the race by making freeze_task() always go through
    fake_signal_wake_up() for applicable tasks.  The function goes through
    the target task's scheduler lock and thus guarantees that either the
    target sees TIF_FREEZE or try_to_freeze_task() sees TASK_RUNNING.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
PM: wakelocks: Don't report wake up wakelock if suspend aborted

If the wakelock driver aborts suspend due to an already-held
wakelock, don't report the next wakelock held as the "wake up
wakelock".

Change-Id: I582ffbb87a3c361739a77d839a0c62921cff11a6
Signed-off-by: Todd Poynor <toddpoynor@google.com>
PM: wakelocks: Display wakelocks preventing suspend by default

Use DEBUG_WAKEUP flag to show wakelocks that abort suspend, in
addition to showing wakelocks held during system resume.
DEBUG_WAKEUP is enabled by default.

Change-Id: If6fa68e8afbc482a5300ffab2964694b02b34f41
Signed-off-by: Todd Poynor <toddpoynor@google.com>
init/calibrate.c: fix for critical bogoMIPS intermittent calculation failure

    A fix to the TSC (Time Stamp Counter) based bogoMIPS calculation used on
    secondary CPUs which has two faults:

    1: Not handling wrapping of the lower 32 bits of the TSC counter on
       32bit kernel - perhaps TSC is not reset by a warm reset?

    2: TSC and Jiffies are no incrementing together properly.  Either
       jiffies increment too quickly or Time Stamp Counter isn't incremented
       in during an SMI but the real time clock is and jiffies are
       incremented.

    Case 1 can result in a factor of 16 too large a value which makes udelay()
    values too small and can cause mysterious driver errors.  Case 2 appears
    to give smaller 10-15% errors after averaging but enough to cause
    occasional failures on my own board

    I have tested this code on my own branch and attach patch suitable for
    current kernel code.  See below for examples of the failures and how the
    fix handles these situations now.

    I reported this issue earlier here:
         Intermittent problem with BogoMIPs calculation on Intel AP CPUs -
    http://marc.info/?l=linux-kernel&m=129947246316875&w=4

    I suspect this issue has been seen by others but as it is intermittent and
    bogoMIPS for secondary CPUs are no longer printed out it might have been
    difficult to identify this as the cause.  Perhaps these unresolved issues,
    although quite old, might be relevant as possibly this fault has been
    around for a while.  In particular Case 1 may only be relevant to 32bit
    kernels on newer HW (most people run 64bit kernels?).  Case 2 is less
    dramatic since the earlier fix in this area and also intermittent.

       Re: bogomips discrepancy on Intel Core2 Quad CPU -
    http://marc.info/?l=linux-kernel&m=118929277524298&w=4
       slow system and bogus bogomips  -
    http://marc.info/?l=linux-kernel&m=116791286716107&w=4
       Re: Re: [RFC-PATCH] clocksource: update lpj if clocksource has -
    http://marc.info/?l=linux-kernel&m=128952775819467&w=4

    This issue is masked a little by commit feae3203d711db0a ("timers, init:
    Limit the number of per cpu calibration bootup messages") which only
    prints out the first bogoMIPS value making it much harder to notice other
    values differing.  Perhaps it should be changed to only suppress them when
    they are similar values?

    Here are some outputs showing faults occurring and the new code handling
    them properly.  See my earlier message for examples of the original
    failure.

        Case 1:   A Time Stamp Counter wrap:
    ...
    Calibrating delay loop (skipped), value calculated using timer
    frequency.. 6332.70 BogoMIPS (lpj=31663540)
    ....
    calibrate_delay_direct() timer_rate_max=31666493
    timer_rate_min=31666151 pre_start=4170369255 pre_end=4202035539
    calibrate_delay_direct() timer_rate_max=2425955274
    timer_rate_min=2425954941 pre_start=4265368533 pre_end=2396356387
    calibrate_delay_direct() ignoring timer_rate as we had a TSC wrap
    around start=4265368581 >=post_end=2396356511
    calibrate_delay_direct() timer_rate_max=31666274
    timer_rate_min=31665942 pre_start=2440373374 pre_end=2472039515
    calibrate_delay_direct() timer_rate_max=31666492
    timer_rate_min=31666160 pre_start=2535372139 pre_end=2567038422
    calibrate_delay_direct() timer_rate_max=31666455
    timer_rate_min=31666207 pre_start=2630371084 pre_end=2662037415
    Calibrating delay using timer specific routine.. 6333.28 BogoMIPS (lpj=31666428)
    Total of 2 processors activated (12665.99 BogoMIPS).
    ....

        Case 2:  Some thing (presumably the SMM interrupt?) causing the
    very low increase in TSC counter for the DELAY_CALIBRATION_TICKS
    increase in jiffies
    ...
    Calibrating delay loop (skipped), value calculated using timer
    frequency.. 6333.25 BogoMIPS (lpj=31666270)
    ...
    calibrate_delay_direct() timer_rate_max=31666483
    timer_rate_min=31666074 pre_start=4199536526 pre_end=4231202809
    calibrate_delay_direct() timer_rate_max=864348 timer_rate_min=864016
    pre_start=2405343672 pre_end=2406207897
    calibrate_delay_direct() timer_rate_max=31666483
    timer_rate_min=31666179 pre_start=2469540464 pre_end=2501206823
    calibrate_delay_direct() timer_rate_max=31666511
    timer_rate_min=31666122 pre_start=2564539400 pre_end=2596205712
    calibrate_delay_direct() timer_rate_max=31666084
    timer_rate_min=31665685 pre_start=2659538782 pre_end=2691204657
    calibrate_delay_direct() dropping min bogoMips estimate 1 = 864348
    Calibrating delay using timer specific routine.. 6333.27 BogoMIPS (lpj=31666390)
    Total of 2 processors activated (12666.53 BogoMIPS).
    ...

    After 70 boots I saw 2 variations <1% slip through

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix straggly printk mess]
    Signed-off-by: Andrew Worsley <amworsley@gmail.com>
    Reviewed-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
init/calibrate.c: remove annoying printk

    Remove calibrate_delay_direct()'s KERN_DEBUG printk related to bogomips
    calculation as it appears when booting every core on setups with
    'ignore_loglevel' which dmesg people scan for possible issues.  As the
    message doesn't show very useful information to the widest audience of
    kernel boot message gazers, it should be removed.

    Introduced by commit d2b463135f84 ("init/calibrate.c: fix for critical
    bogoMIPS intermittent calculation failure").

    Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
    Cc: Andrew Worsley <amworsley@gmail.com>
    Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
init: skip calibration delay if previously done

    For each CPU, do the calibration delay only once.  For subsequent calls,
    use the cached per-CPU value of loops_per_jiffy.

    This saves about 200ms of resume time on dual core Intel Atom N5xx based
    systems.  This helps bring down the kernel resume time on such systems
    from about 500ms to about 300ms.

    [akpm@linux-foundation.org: make cpu_loops_per_jiffy static]
    [akpm@linux-foundation.org: clean up message text]
    [akpm@linux-foundation.org: fix things up after upstream rmk changes]
    Signed-off-by: Sameer Nanda <snanda@chromium.org>
    Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
    Cc: Andrew Worsley <amworsley@gmail.com>
    Cc: David Daney <ddaney@caviumnetworks.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert "enable autogroup"

This reverts commit 615cd64c1dc28afde5135fc25e771214c49d1ee5.
Revert "cgroup: Remove call to synchronize_rcu in cgroup_attach_task"

This reverts commit ae79d1968bfa3155a98d0ce2a519c35a498638c5.
Revert "cgroup: Set CGRP_RELEASABLE when adding to a cgroup"

This reverts commit dfb6868973102b48effd5f17f2bc2483c6264ad7.
Revert "sched, autogroup: More fixes for autogroup so that it actually works"

This reverts commit 46cb1a8e7d2669ac15e12e18f01f045419371308.
Revert "sched, autogroup: Autogroups and fixes."

This reverts commit 1723930e48a1fab22fcfb2982fbc38e4b83ceb64.
ADD: rcu: Add a TINY_PREEMPT_RCU

    Implement a small-memory-footprint uniprocessor-only implementation of
    preemptible RCU.  This implementation uses but a single blocked-tasks
    list rather than the combinatorial number used per leaf rcu_node by
    TREE_PREEMPT_RCU, which reduces memory consumption and greatly simplifies
    processing.  This version also takes advantage of uniprocessor execution
    to accelerate grace periods in the case where there are no readers.

    The general design is otherwise broadly similar to that of TREE_PREEMPT_RCU.

    This implementation is a step towards having RCU implementation driven
    off of the SMP and PREEMPT kernel configuration variables, which can
    happen once this implementation has accumulated sufficient experience.

    Removed ACCESS_ONCE() from __rcu_read_unlock() and added barrier() as
    suggested by Steve Rostedt in order to avoid the compiler-reordering
    issue noted by Mathieu Desnoyers (http://lkml.org/lkml/2010/8/16/183).

    As can be seen below, CONFIG_TINY_PREEMPT_RCU represents almost 5Kbyte
    savings compared to CONFIG_TREE_PREEMPT_RCU.  Of course, for non-real-time
    workloads, CONFIG_TINY_RCU is even better.

    	CONFIG_TREE_PREEMPT_RCU

    	   text	   data	    bss	    dec	   filename
    	     13	      0	      0	     13	   kernel/rcupdate.o
    	   6170	    825	     28	   7023	   kernel/rcutree.o
    				   ----
    				   7026    Total

    	CONFIG_TINY_PREEMPT_RCU

    	   text	   data	    bss	    dec	   filename
    	     13	      0	      0	     13	   kernel/rcupdate.o
    	   2081	     81	      8	   2170	   kernel/rcutiny.o
    				   ----
    				   2183    Total

    	CONFIG_TINY_RCU (non-preemptible)

    	   text	   data	    bss	    dec	   filename
    	     13	      0	      0	     13	   kernel/rcupdate.o
    	    719	     25	      0	    744	   kernel/rcutiny.o
    				    ---
    				    757    Total

    Requested-by: Loïc Minier <loic.minier@canonical.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
rcu: apply TINY_PREEMPT_RCU read-side speedup to TREE_PREEMPT_RCU

    Replace one of the ACCESS_ONCE() calls in each of __rcu_read_lock()
    and __rcu_read_unlock() with barrier() as suggested by Steve Rostedt in
    order to avoid the potential compiler-optimization-induced bug noted by
    Mathieu Desnoyers.

    Located-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
rcu: move TINY_RCU from softirq to kthread

    If RCU priority boosting is to be meaningful, callback invocation must
    be boosted in addition to preempted RCU readers.  Otherwise, in presence
    of CPU real-time threads, the grace period ends, but the callbacks don't
    get invoked.  If the callbacks don't get invoked, the associated memory
    doesn't get freed, so the system is still subject to OOM.

    But it is not reasonable to priority-boost RCU_SOFTIRQ, so this commit
    moves the callback invocations to a kthread, which can be boosted easily.

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
rcu: priority boosting for TINY_PREEMPT_RCU

    Add priority boosting, but only for TINY_PREEMPT_RCU.  This is enabled
    by the default-off RCU_BOOST kernel parameter.  The priority to which to
    boost preempted RCU readers is controlled by the RCU_BOOST_PRIO kernel
    parameter (defaulting to real-time priority 1) and the time to wait
    before boosting the readers blocking a given grace period is controlled
    by the RCU_BOOST_DELAY kernel parameter (defaulting to 500 milliseconds).

    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
rcu: avoid pointless blocked-task warnings

    If the RCU callback-processing kthread has nothing to do, it parks in
    a wait_event().  If RCU remains idle for more than two minutes, the
    kernel complains about this.  This commit changes from wait_event()
    to wait_event_interruptible() to prevent the kernel from complaining
    just because RCU is idle.

    Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Thomas Weber <weber@corscience.de>
    Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>