cpufreq: Save user policy min/max instead of policy min/max during hotplug

When a CPU is hotplugged off, various fields of the policy are saved so
that they can be restored when the CPU is hotplugged back in.

The existing code saves the policy min/max field during hotplug remove and
restores it into user policy min/max during hotplug add. This results in
the loss of the user policy min/max values across a hotplug remove/add.

Fix it by saving the user policy min/max instead of policy min/max during
hotplug remove. During a hotplug add, after user policy min/max is
restored, the policy min/max is already recomputed. So, there's no risk of
going beyound any limits imposed by the CPUFREQ_ADJUST/INCOMPATIBLE
notifiers.

Change-Id: Ib8e09fa324c1f80f095c5754b5dcf2685e8e4a66
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
drivers/cpufreq/cpufreq.c: re-enable cpu policy restore

original bug FINALLY fixed by:
  cpufreq: Save user policy min/max instead of policy min/max during hotplug

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:

	drivers/cpufreq/cpufreq.c
net: flow: Prevent bringing up new CPUs during per-CPU initialization

In a rare race-condition, it's possible that a CPU will be brought
online between when the for_each_online_cpu() loop executes to
call flow_cache_cpu_prepare(), and when the hotplug notifier for
calling this same function is registered. If this happens,
flow_cache_cpu_prepare() will never be called for the new CPU,
resulting in crashes due to uninitialized per-cpu data.

Fix this by preventing CPUs from being added or removed during
this small but sensitive window.

Change-Id: Iafbbaa8a50e5c527392d130561874313720849d0
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
sched: Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s

try_to_wake_up_local() should only be invoked to wake up another
task in the same runqueue and BUG_ON()s are used to enforce the
rule. Missing try_to_wake_up_local() can stall workqueue
execution but such stalls are likely to be finite either by
another work item being queued or the one blocked getting
unblocked.  There's no reason to trigger BUG while holding rq
lock crashing the whole system.

Convert BUG_ON()s in try_to_wake_up_local() to WARN_ON_ONCE()s.

Change-Id: I75fdaaf4dcaefcf3893e0404d98c8aa91f89934d
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20130318192234.GD3042@htj.dyndns.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Git-commit: 383efcd00053ec40023010ce5034bd702e7ab373
CRs-Fixed: 519942
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>

Conflicts:

	kernel/sched/core.c