sched: Fix HRTICK

David reported that the HRTICK sched feature was borken; which was enough
motivation for me to finally fix it ;-)

We should not allow hrtimer code to do softirq wakeups while holding scheduler
locks. The hrtimer code only needs this when we accidentally try to program an
expired time. We don't much care about those anyway since we have the regular
tick to fall back to.

Reported-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20130628091853.GE29209@dyad.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Revert: add Optimized ARM RWSEM algorithm
Revert "ARM: allow the kernel text section to be made read-only"

This reverts commit e5e483d13369ab62d95f1738edce3cd64c7ca2ff.

This change breaks LPAE support. Other patches provide the same
functionality so just revert the patch.

Change-Id: Iea1e88064a1618ca1fc9d717ee5a4ffe77681745
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Revert: Freezer: "HACK: ARM: disable sleeping while atomic warning in do_signal"

It's not needed anymore since commit: 'arm: don't call try_to_freeze() from do_signal()'

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/arch/arm/kernel/signal.c?id=d9be5ea6f9b6a51535ccdd9881ffb3be2dbd48e9
Revert "fix definition of 'finish_arch_switch()'"

This reverts commit 8b973c07fe2e6fd7455079cebc9eaa2eb14826b8.
fix definition of 'finish_arch_switch()' v2

Commit b2628c861cd67e447242227876096b105b3be6e1
	('ARM: spinlock: use inner-shareable dsb variant prior to sev instruction')

...introduced a defintion for: 'finish_arch_switch()'

On MSM kernels this got however already defined at:
		arch/arm/mach-msm/include/mach/memory.h

Fix it by extending the existing MSM definition by the
one of ARM.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
arm: mm: Define set_memory_* functions for ARM

Other architectures define various set_memory functions to allow
attributes to be changed (e.g. set_memory_x, set_memory_rw, etc.)
Currently, these functions are missing on ARM. Define these in an
appropriate manner for ARM.

Change-Id: I5083aa985d31e195f138ce7ed26d2a1d4b80faae
CRs-Fixed: 498398
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
arm: Add definitions for pte_mkexec/pte_mknexec

Other architectures define pte_mkexec to mark a pte as executable.
Add pte_mkexec for ARM to get the same functionality. Although no
other architectures currently define it, also add pte_mknexec to
explicitly allow a pte to be marked as non executable.

Change-Id: I673b48a1d93bf00682edbb3609a478eb28eb67a1
CRs-Fixed: 498398
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ARM: SoC: add per-platform SMP operations

This adds a 'struct smp_operations' to abstract the CPU initialization
and hot plugging functions on SMP systems, which otherwise conflict
in a multiplatform kernel. This also helps shmobile and potentially
others that have more than one method to do these.

To allow the kernel to continue building, the platform hooks are
defined as weak symbols which are overrided by the platform code.
Once all platforms are converted, the "weak" attribute will be
removed and the function made static.

Unlike the original version from Marc, this new version from Arnd
does not use a generalized abstraction for per-soc data structures
but only tries to solve the problem for the SMP operations. This
way, we can collapse the previous four data structures into a
single struct, which is less systematic but also easier to follow
as a causal reader.

Change-Id: I9d022d4e789f8f87f26a237fa2e9e410be070976
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[rameezmustafa@codeaurora.org: backport to kernel 3.4]
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Patch-mainline: v3.7
Git-commit: abcee5fb0dfbb248d883a2f6bdb4820abe3ac524

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: cache_l2x0: Set outer_cache resume

Set the outer_cache.resume function during l2x0_init and declare a static
inline void version to allow compilation when OUTER_CACHE is not defined.
The outer_cache functions are used for L2 cache management in chips that
have an external cache controller. The outer_cache.resume re-enables the
L2 cache controller and is called when exiting power collapse.
This change is needed to allow drivers to call outer_cache API's instead
of directly using the APIs defined in cache-l2x0.c and thus avoid having
to use #ifdef macros in the code.

Change-Id: Ifc7d25f905e3248f864c9eaf019436968e77b8a2
Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
smp: patches from mainline 3.5 to hopefully help with hotplug efficiency

Thomas Gleixner's generic-idle patches:

smp: Add task_struct argument to __cpu_up()
	Preparatory patch to make the idle thread allocation for secondary
	cpus generic.
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=8239c25f47d2b318156993b15f33900a86ea5e17

smp: Add generic smpboot facility
	Start a new file, which will hold SMP and CPU hotplug related generic
	infrastructure.
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=38498a67aa2cf8c80754b8d304bfacc10bc582b5

smp: Provide generic idle thread allocation
	All SMP architectures have magic to fork the idle task and to store it
	for reusage when cpu hotplug is enabled. Provide a generic
	infrastructure for it.
	Create/reinit the idle thread for the cpu which is brought up in the
	generic code and hand the thread pointer to the architecture code via
	__cpu_up().
	Note, that fork_idle() is called via a workqueue, because this
	guarantees that the idle thread does not get a reference to a user
	space VM. This can happen when the boot process did not bring up all
	possible cpus and a later cpu_up() is initiated via the sysfs
	interface. In that case fork_idle() would be called in the context of
	the user space task and take a reference on the user space VM.
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=29d5e0476e1c4a513859e7858845ad172f560389

arm: Use generic idle thread allocation
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commit;h=84ec6d5796e095e2f8698bd2b5d33849ed26d9e2

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

smp, idle: Allocate idle thread for each possible cpu during boot

	percpu areas are already allocated during boot for each possible cpu.
	percpu idle threads can be considered as an extension of the percpu areas,
	and allocate them for each possible cpu during boot.

	This will eliminate the need for workqueue based idle thread allocation.
	In future we can move the idle thread area into the percpu area too.

	[ tglx: Moved the loop into smpboot.c and added an error check when
	the init code failed to allocate an idle thread for a cpu which
	should be onlined ]

smpboot, idle: Optimize calls to smp_processor_id() in idle_threads_init()

	While trying to initialize idle threads for all cpus, idle_threads_init()
	calls smp_processor_id() in a loop, which is unnecessary. The intent
	is to initialize idle threads for all non-boot cpus. So just use a variable
	to note the boot cpu and use it in the loop.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
lglock: *squashing updates*

lglock: remove online variants of lock

	Optimizing the slow paths adds a lot of complexity.  If you need to
	grab every lock often, you have other problems.

	Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
	Acked-by: Nick Piggin <npiggin@kernel.dk>
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

brlocks/lglocks: turn into functions

	lglocks and brlocks are currently generated with some complicated macros
	in lglock.h.  But there's no reason to not just use common utility
	functions and put all the data into a common data structure.

	Since there are at least two users it makes sense to share this code in a
	library.  This is also easier maintainable than a macro forest.

	This will also make it later possible to dynamically allocate lglocks and
	also use them in modules (this would both still need some additional, but
	now straightforward, code)

	[akpm@linux-foundation.org: checkpatch fixes]
	Signed-off-by: Andi Kleen <ak@linux.intel.com>
	Cc: Al Viro <viro@zeniv.linux.org.uk>
	Cc: Rusty Russell <rusty@rustcorp.com.au>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

brlocks/lglocks: API cleanups

	lglocks and brlocks are currently generated with some complicated macros
	in lglock.h.  But there's no reason to not just use common utility
	functions and put all the data into a common data structure.

	In preparation, this patch changes the API to look more like normal
	function calls with pointers, not magic macros.

	The patch is rather large because I move over all users in one go to keep
	it bisectable.  This impacts the VFS somewhat in terms of lines changed.
	But no actual behaviour change.

	[akpm@linux-foundation.org: checkpatch fixes]
	Signed-off-by: Andi Kleen <ak@linux.intel.com>
	Cc: Al Viro <viro@zeniv.linux.org.uk>
	Cc: Rusty Russell <rusty@rustcorp.com.au>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

lglock: Update lockdep annotations to report recursive local locks

	Oleg Nesterov recently noticed that the lockdep annotations in lglock.c
	are not sufficient to detect some obvious deadlocks, such as
	lg_local_lock(LOCK) + lg_local_lock(LOCK) or spin_lock(X) +
	lg_local_lock(Y) vs lg_local_lock(Y) + spin_lock(X).

	Both issues are easily fixed by indicating to lockdep that lglock's local
	locks are not recursive.  We shouldn't use the rwlock acquire/release
	functions here, as lglock doesn't share the same semantics.  Instead we
	can base our lockdep annotations on the lock_acquire_shared (for local
	lglock) and lock_acquire_exclusive (for global lglock) helpers.

	I am not proposing new lglock specific helpers as I don't see the point of
	the existing second level of helpers :)

	Noticed-by: Oleg Nesterov <oleg@redhat.com>
	Signed-off-by: Michel Lespinasse <walken@google.com>
	Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
	Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
	Cc: Rusty Russell <rusty@rustcorp.com.au>
	Cc: Andi Kleen <ak@linux.intel.com>
	Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
	Cc: Steven Rostedt <rostedt@goodmis.org>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Peter Zijlstra <peterz@infradead.org>
	Link: http://lkml.kernel.org/r/20130708212352.1769031C15E@corp2gmr1-1.hot.corp.google.com
	Signed-off-by: Ingo Molnar <mingo@kernel.org>

lglock: remove unused DEFINE_LGLOCK_LOCKDEP()

	struct lglocks use their own lock_key/lock_dep_map which are defined in
	struct lglock.  DEFINE_LGLOCK_LOCKDEP() is unused, so remove it and save a
	small piece of memory.

	Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
	Cc: Alexander Viro <viro@zeniv.linux.org.uk>
	Cc: Rusty Russell <rusty@rustcorp.com.au>
	Cc: Andi Kleen <ak@linux.intel.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

lglock: make the per_cpu locks static

	The per_cpu locks are not used outside the file which contains the
	DEFINE_LGLOCK(), so we can make these symbols static.

	Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
	Cc: Alexander Viro <viro@zeniv.linux.org.uk>
	Cc: Rusty Russell <rusty@rustcorp.com.au>
	Cc: Andi Kleen <ak@linux.intel.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

lglock: add DEFINE_STATIC_LGLOCK()

	When the lglock doesn't need to be exported we can use
	DEFINE_STATIC_LGLOCK().

	Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
	Cc: Alexander Viro <viro@zeniv.linux.org.uk>
	Cc: Rusty Russell <rusty@rustcorp.com.au>
	Cc: Andi Kleen <ak@linux.intel.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
lockdep: *squashing updates*

lockdep: Check if nested lock is actually held

	It is considered good form to lock the lock you claim to be nested in.

	Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>

	[ removed nest_lock arg to print_lock_nested_lock_not_held in favour
	of hlock->nest_lock, also renamed the lock arg to hlock since its
	a held_lock type ]
	Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
	Link: http://lkml.kernel.org/r/5051A9E7.5040501@canonical.com
	Signed-off-by: Ingo Molnar <mingo@kernel.org>

lockdep: Rename print_unlock_inbalance_bug() to print_unlock_imbalance_bug()

	Fix the typo in the function name (s/inbalance/imbalance)

	Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
	Cc: rostedt@goodmis.org
	Cc: peterz@infradead.org
	Link: http://lkml.kernel.org/r/20130108130547.32733.79507.stgit@srivatsabhat.in.ibm.com
	Signed-off-by: Ingo Molnar <mingo@kernel.org>

lockdep: Print more info when MAX_LOCK_DEPTH is exceeded

	This helps debug cases where a lock is acquired over and
	over without being released.

	Suggested-by: Steven Rostedt <rostedt@goodmis.org>
	Signed-off-by: Ben Greear <greearb@candelatech.com>
	Cc: peterz@infradead.org
	Link: http://lkml.kernel.org/r/1360176979-4421-1-git-send-email-greearb@candelatech.com
	[ Changed the printout ordering. ]
	Signed-off-by: Ingo Molnar <mingo@kernel.org>

Export __lockdep_no_validate__

	Hack, but bcache needs a way around lockdep for locking during garbage
	collection - we need to keep multiple btree nodes locked for coalescing
	and rw_lock_nested() isn't really sufficient or appropriate here.

	Signed-off-by: Kent Overstreet <koverstreet@google.com>
	CC: Peter Zijlstra <peterz@infradead.org>
	CC: Ingo Molnar <mingo@redhat.com>

lockdep: Remove unnecessary 'hlock_next' variable

	Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
	Cc: peterz@infradead.org
	Link: http://lkml.kernel.org/r/1365058881-4044-1-git-send-email-honkiko@gmail.com
	Signed-off-by: Ingo Molnar <mingo@kernel.org>

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>

lockdep, rwsem: provide down_write_nest_lock()

	down_write_nest_lock() provides a means to annotate locking scenario
	where an outer lock is guaranteed to serialize the order nested locks
	are being acquired.

	This is analogoue to already existing mutex_lock_nest_lock() and
	spin_lock_nest_lock().

	Signed-off-by: Jiri Kosina <jkosina@suse.cz>
	Cc: Rik van Riel <riel@redhat.com>
	Cc: Ingo Molnar <mingo@kernel.org>
	Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
	Cc: Mel Gorman <mel@csn.ul.ie>
	Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lockdep: Silence warning if CONFIG_LOCKDEP isn't set

	Since commit c9a4962881929df7f1ef6e63e1b9da304faca4dd ("nfsd:
	make client_lock per net") compiling nfs4state.o without
	CONFIG_LOCKDEP set, triggers this GCC warning:

	fs/nfsd/nfs4state.c: In function ‘free_client’:
	fs/nfsd/nfs4state.c:1051:19: warning: unused variable ‘nn’ [-Wunused-variable]

	The cause of that warning is that lockdep_assert_held() compiles
	away if CONFIG_LOCKDEP is not set. Silence this warning by using
	the argument to lockdep_assert_held() as a nop if CONFIG_LOCKDEP
	is not set.

	Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
	Cc: Peter Zijlstra <peterz@infradead.org>
	Cc: Stanislav Kinsbursky <skinsbursky@parallels.com>
	Cc: J. Bruce Fields <bfields@redhat.com>
	Link: http://lkml.kernel.org/r/1359060797.1325.33.camel@x61.thuisdomein
	Signed-off-by: Ingo Molnar <mingo@kernel.org>

lockdep: make lockdep_assert_held() not have a return value

	I recently made the mistake of writing:

	foo = lockdep_dereference_protected(..., lockdep_assert_held(...));

	which is clearly bogus.  If lockdep is disabled in the config this would
	cause a compile failure, if it is enabled then it compiles and causes a
	puzzling warning about dereferencing without the correct protection.

	Wrap the macro in "do { ...  } while (0)" to also fail compile for this
	when lockdep is enabled.

	Signed-off-by: Johannes Berg <johannes.berg@intel.com>
	Cc: Peter Zijlstra <peterz@infradead.org>
	Cc: Ingo Molnar <mingo@redhat.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lockdep: Introduce lock_acquire_exclusive()/shared() helper macros

	In lockdep.h, the spinlock/mutex/rwsem/rwlock/lock_map acquire macros have
	different definitions based on the value of CONFIG_PROVE_LOCKING.  We have
	separate ifdefs for each of these definitions, which seems redundant.

	Introduce lock_acquire_{exclusive,shared,shared_recursive} helpers which
	will have different definitions based on CONFIG_PROVE_LOCKING.  Then all
	other helper macros can be defined based on the above ones, which reduces
	the amount of ifdefined code.

	Signed-off-by: Michel Lespinasse <walken@google.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
	Signed-off-by: Peter Zijlstra <peterz@infradead.org>
	Cc: Oleg Nesterov <oleg@redhat.com>
	Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
	Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
	Cc: Rusty Russell <rusty@rustcorp.com.au>
	Cc: Andi Kleen <ak@linux.intel.com>
	Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
	Cc: Steven Rostedt <rostedt@goodmis.org>
	Link: http://lkml.kernel.org/r/20130708212350.6DD1931C15E@corp2gmr1-1.hot.corp.google.com
	Signed-off-by: Ingo Molnar <mingo@kernel.org>

asmlinkage: Make lockdep_sys_exit asmlinkage

	lockdep_sys_exit can be called from assembler code, so make it
	asmlinkage.

	Cc: Peter Zijlstra <peterz@infradead.org>
	Cc: Ingo Molnar <mingo@kernel.org>
	Signed-off-by: Andi Kleen <ak@linux.intel.com>
	Link: http://lkml.kernel.org/r/1391845930-28580-5-git-send-email-ak@linux.intel.com
	Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
cgroup: mark subsystems with broken hierarchy support and whine if cgroups are nested for them

Currently, cgroup hierarchy support is a mess.  cpu related subsystems
behave correctly - configuration, accounting and control on a parent
properly cover its children.  blkio and freezer completely ignore
hierarchy and treat all cgroups as if they're directly under the root
cgroup.  Others show yet different behaviors.

These differing interpretations of cgroup hierarchy make using cgroup
confusing and it impossible to co-mount controllers into the same
hierarchy and obtain sane behavior.

Eventually, we want full hierarchy support from all subsystems and
probably a unified hierarchy.  Users using separate hierarchies
expecting completely different behaviors depending on the mounted
subsystem is deterimental to making any progress on this front.

This patch adds cgroup_subsys.broken_hierarchy and sets it to %true
for controllers which are lacking in hierarchy support.  The goal of
this patch is two-fold.

* Move users away from using hierarchy on currently non-hierarchical
  subsystems, so that implementing proper hierarchy support on those
  doesn't surprise them.

* Keep track of which controllers are broken how and nudge the
  subsystems to implement proper hierarchy support.

For now, start with a single warning message.  We can whine louder
later on.

v2: Fixed a typo spotted by Michal. Warning message updated.

v3: Updated memcg part so that it doesn't generate warning in the
    cases where .use_hierarchy=false doesn't make the behavior
    different from root.use_hierarchy=true.  Fixed a typo spotted by
    Glauber.

v4: Check ->broken_hierarchy after cgroup creation is complete so that
    ->create() can affect the result per Michal.  Dropped unnecessary
    memcg root handling per Michal.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Li Zefan <lizefan@huawei.com>
Acked-by: Serge E. Hallyn <serue@us.ibm.com>
Cc: Glauber Costa <glommer@parallels.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Turner <pjt@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
cgroup: cgroup_subsys->fork() should be called after the task is added to css_set

cgroup core has a bug which violates a basic rule about event
notifications - when a new entity needs to be added, you add that to
the notification list first and then make the new entity conform to
the current state.  If done in the reverse order, an event happening
inbetween will be lost.

cgroup_subsys->fork() is invoked way before the new task is added to
the css_set.  Currently, cgroup_freezer is the only user of ->fork()
and uses it to make new tasks conform to the current state of the
freezer.  If FROZEN state is requested while fork is in progress
between cgroup_fork_callbacks() and cgroup_post_fork(), the child
could escape freezing - the cgroup isn't frozen when ->fork() is
called and the freezer couldn't see the new task on the css_set.

This patch moves cgroup_subsys->fork() invocation to
cgroup_post_fork() after the new task is added to the css_set.
cgroup_fork_callbacks() is removed.

Because now a task may be migrated during cgroup_subsys->fork(),
freezer_fork() is updated so that it adheres to the usual RCU locking
and the rather pointless comment on why locking can be different there
is removed (if it doesn't make anything simpler, why even bother?).

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@vger.kernel.org
cgroup_freezer: make it official that writes to freezer.state don't fail

	try_to_freeze_cgroup() has condition checks which are intended to fail
	the write operation to freezer.state if there are tasks which can't be
	frozen.  The condition checks have been broken for quite some time
	now.  freeze_task() returns %false if the target task can't be frozen,
	so num_cant_freeze_now is never incremented.

	In addition, strangely, cgroup freezing proceeds even after the write
	is failed, which is rather broken.

	This patch rips out the non-working code intended to fail the write to
	freezer.state when the cgroup contains non-freezable tasks and makes
	it official that writes to freezer.state succeed whether there are
	non-freezable tasks in the cgroup or not.

	This leaves is_task_frozen_enough() with only one user -
	upste_if_frozen().  Collapse it into the caller.  Note that this
	removes an extra call to freezing().

	This doesn't cause any userland behavior changes.

	Signed-off-by: Tejun Heo <tj@kernel.org>
	Cc: Oleg Nesterov <oleg@redhat.com>
	Cc: Rafael J. Wysocki <rjw@sisk.pl>

cgroup_freezer: don't stall transition to FROZEN for PF_NOFREEZE or PF_FREEZER_SKIP tasks

	cgroup_freezer doesn't transition from FREEZING to FROZEN if the
	cgroup contains PF_NOFREEZE tasks or tasks sleeping with
	PF_FREEZER_SKIP set.

	Only kernel tasks can be non-freezable (PF_NOFREEZE) and there's
	nothing cgroup_freezer or userland can do about or to it.  It's
	pointless to stall the transition for PF_NOFREEZE tasks.

	PF_FREEZER_SKIP indicates that the task can be skipped when
	determining whether frozen state is reached.  A task with
	PF_FREEZER_SKIP is guaranteed to perform try_to_freeze() after it
	wakes up and can be considered frozen much like stopped or traced
	tasks.  Note that a vfork parent uses PF_FREEZER_SKIP while waiting
	for the child.

	This updates update_if_frozen() such that it only considers freezable
	tasks and treats %true freezer_should_skip() tasks as frozen.

	This allows cgroups w/ kthreads and vfork parents successfully reach
	FROZEN state.

	Signed-off-by: Tejun Heo <tj@kernel.org>
	Cc: Oleg Nesterov <oleg@redhat.com>
	Cc: Rafael J. Wysocki <rjw@sisk.pl>

cgroup_freezer: allow moving tasks in and out of a frozen cgroup

	cgroup_freezer is one of the few users of cgroup_subsys->can_attach()
	and uses it to prevent tasks from being migrated into or out of a
	frozen cgroup.  This makes cgroup_freezer cumbersome to use especially
	when co-mounted with other controllers.

	->can_attach() is problematic in general as it can make co-mounting
	multiple cgroups difficult - migrating tasks may fail for reasons
	completely irrelevant for other controllers.  freezer_can_attach() in
	particular is more problematic because it messes with cgroup internal
	locking to ensure that the state verification performed at
	freezer_can_attach() stays valid until migration is complete.

	This patch replaces freezer_can_attach() with freezer_attach() so that
	tasks are always allowed to migrate - they are nudged into the
	conforming state from freezer_attach().  This means that there can be
	tasks which are being migrated which don't conform to the current
	cgroup_freezer state until freezer_attach() is complete.  Under the
	current locking scheme, the only such place is freezer_fork() which is
	updated to handle such window.

	While this patch doesn't remove the use of internal cgroup locking
	from freezer_read/write() paths, it removes the requirement to keep
	the freezer state constant while migrating and enables such change.

	Note that this creates a userland visible behavior change - FROZEN
	cgroup can no longer be used to lock migrations in and out of the
	cgroup.  This behavior change is intended.  I don't think the feature
	is necessary - userland should coordinate accesses to cgroup fs anyway
	- and even if the feature is needed cgroup_freezer is the completely
	wrong place to implement it.

	Signed-off-by: Tejun Heo <tj@kernel.org>
	LKML-Reference: <1350426526-14254-1-git-send-email-tj@kernel.org>
	Cc: Matt Helsley <matthltc@linux.vnet.ibm.com>
	Cc: Oleg Nesterov <oleg@redhat.com>
	Cc: Rafael J. Wysocki <rjw@sisk.pl>
	Cc: Li Zefan <lizefan@huawei.com>

cgroup_freezer: prepare update_if_frozen() for locking change

	Locking will change such that migration can happen while
	freezer_read/write() is in progress.  This means that
	update_if_frozen() can no longer assume that all tasks in the cgroup
	coform to the current freezer state - newly migrated tasks which
	haven't finished freezer_attach() yet might be in any state.

	This patch updates update_if_frozen() such that it no longer verifies
	task states against freezer state.  It now simply decides whether
	FREEZING stage is complete.

	This removal of verification makes it meaningless to call from
	freezer_change_state().  Drop it and move the fast exit test from
	freezer_read() - the only left caller - to update_if_frozen().

	Signed-off-by: Tejun Heo <tj@kernel.org>
	Cc: Oleg Nesterov <oleg@redhat.com>
	Cc: Rafael J. Wysocki <rjw@sisk.pl>
	Cc: Li Zefan <lizefan@huawei.com>

cgroup_freezer: don't use cgroup_lock_live_group()

	freezer_read/write() used cgroup_lock_live_group() to synchronize
	against task migration into and out of the target cgroup.
	cgroup_lock_live_group() grabs the internal cgroup lock and using it
	from outside cgroup core leads to complex and fragile locking
	dependency issues which are difficult to resolve.

	Now that freezer_can_attach() is replaced with freezer_attach() and
	update_if_frozen() updated, nothing requires excluding migration
	against freezer state reads and changes.

	This patch removes cgroup_lock_live_group() and the matching
	cgroup_unlock() usages.  The prone-to-bitrot, already outdated and
	unnecessary global lock hierarchy documentation is replaced with
	documentation in local scope.

	Signed-off-by: Tejun Heo <tj@kernel.org>
	Cc: Oleg Nesterov <oleg@redhat.com>
	Cc: Rafael J. Wysocki <rjw@sisk.pl>
	Cc: Li Zefan <lizefan@huawei.com>

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
freezer: change ptrace_stop/do_signal_stop to use freezable_schedule()

try_to_freeze_tasks() and cgroup_freezer rely on scheduler locks
to ensure that a task doing STOPPED/TRACED -> RUNNING transition
can't escape freezing. This mostly works, but ptrace_stop() does
not necessarily call schedule(), it can change task->state back to
RUNNING and check freezing() without any lock/barrier in between.

We could add the necessary barrier, but this patch changes
ptrace_stop() and do_signal_stop() to use freezable_schedule().
This fixes the race, freezer_count() and freezer_should_skip()
carefully avoid the race.

And this simplifies the code, try_to_freeze_tasks/update_if_frozen
no longer need to use task_is_stopped_or_traced() checks with the
non trivial assumptions. We can rely on the mechanism which was
specially designed to mark the sleeping task as "frozen enough".

v2: As Tejun pointed out, we can also change get_signal_to_deliver()
and move try_to_freeze() up before 'relock' label.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>