Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Mar 4, 2012
  1. Rafael J. Wysocki

    PM / Freezer: Remove references to TIF_FREEZE in comments

    Marcos Paulo de Souza authored rjwysocki committed
    This patch removes all the references in the code about the TIF_FREEZE
    flag removed by commit a320122
    
        freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE
    
    There still are some references to TIF_FREEZE in
    Documentation/power/freezing-of-tasks.txt, but it looks like that
    documentation needs more thorough work to reflect how the new
    freezer works, and hence merely removing the references to TIF_FREEZE
    won't really help. So I have not touched that part in this patch.
    
    Suggested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
    Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Commits on Nov 23, 2011
  1. freezer: kill unused set_freezable_with_signal()

    Tejun Heo authored
    There's no in-kernel user of set_freezable_with_signal() left.  Mixing
    TIF_SIGPENDING with kernel threads can lead to nasty corner cases as
    kernel threads never travel signal delivery path on their own.
    
    e.g. the current implementation is buggy in the cancelation path of
    __thaw_task().  It calls recalc_sigpending_and_wake() in an attempt to
    clear TIF_SIGPENDING but the function never clears it regardless of
    sigpending state.  This means that signallable freezable kthreads may
    continue executing with !freezing() && stuck TIF_SIGPENDING, which can
    be troublesome.
    
    This patch removes set_freezable_with_signal() along with
    PF_FREEZER_NOSIG and recalc_sigpending*() calls in freezer.  User
    tasks get TIF_SIGPENDING, kernel tasks get woken up and the spurious
    sigpending is dealt with in the usual signal delivery path.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
Commits on Nov 21, 2011
  1. freezer: remove unused @sig_only from freeze_task()

    Tejun Heo authored
    After "freezer: make freezing() test freeze conditions in effect
    instead of TIF_FREEZE", freezing() returns authoritative answer on
    whether the current task should freeze or not and freeze_task()
    doesn't need or use @sig_only.  Remove it.
    
    While at it, rewrite function comment for freeze_task() and rename
    @sig_only to @user_only in try_to_freeze_tasks().
    
    This patch doesn't cause any functional change.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
  2. freezer: use lock_task_sighand() in fake_signal_wake_up()

    Tejun Heo authored
    cgroup_freezer calls freeze_task() without holding tasklist_lock and,
    if the task is exiting, its ->sighand may be gone by the time
    fake_signal_wake_up() is called.  Use lock_task_sighand() instead of
    accessing ->sighand directly.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
    Cc: Paul Menage <paul@paulmenage.org>
  3. freezer: restructure __refrigerator()

    Tejun Heo authored
    If another freeze happens before all tasks leave FROZEN state after
    being thawed, the freezer can see the existing FROZEN and consider the
    tasks to be frozen but they can clear FROZEN without checking the new
    freezing().
    
    Oleg suggested restructuring __refrigerator() such that there's single
    condition check section inside freezer_lock and sigpending is cleared
    afterwards, which fixes the problem and simplifies the code.
    Restructure accordingly.
    
    -v2: Frozen loop exited without releasing freezer_lock.  Fixed.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
  4. freezer: fix set_freezable[_with_signal]() race

    Tejun Heo authored
    A kthread doing set_freezable*() may race with on-going PM freeze and
    the freezer might think all tasks are frozen while the new freezable
    kthread is merrily proceeding to execute code paths which aren't
    supposed to be executing during PM freeze.
    
    Reimplement set_freezable[_with_signal]() using __set_freezable() such
    that freezable PF flags are modified under freezer_lock and
    try_to_freeze() is called afterwards.  This eliminates race condition
    against freezing.
    
    Note: Separated out from larger patch to resolve fix order dependency
          Oleg pointed out.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
  5. freezer: remove should_send_signal() and update frozen()

    Tejun Heo authored
    should_send_signal() is only used in freezer.c.  Exporting them only
    increases chance of abuse.  Open code the two users and remove it.
    
    Update frozen() to return bool.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
  6. freezer: make freezing() test freeze conditions in effect instead of …

    Tejun Heo authored
    …TIF_FREEZE
    
    Using TIF_FREEZE for freezing worked when there was only single
    freezing condition (the PM one); however, now there is also the
    cgroup_freezer and single bit flag is getting clumsy.
    thaw_processes() is already testing whether cgroup freezing in in
    effect to avoid thawing tasks which were frozen by both PM and cgroup
    freezers.
    
    This is racy (nothing prevents race against cgroup freezing) and
    fragile.  A much simpler way is to test actual freeze conditions from
    freezing() - ie. directly test whether PM or cgroup freezing is in
    effect.
    
    This patch adds variables to indicate whether and what type of
    freezing conditions are in effect and reimplements freezing() such
    that it directly tests whether any of the two freezing conditions is
    active and the task should freeze.  On fast path, freezing() is still
    very cheap - it only tests system_freezing_cnt.
    
    This makes the clumsy dancing aroung TIF_FREEZE unnecessary and
    freeze/thaw operations more usual - updating state variables for the
    new state and nudging target tasks so that they notice the new state
    and comply.  As long as the nudging happens after state update, it's
    race-free.
    
    * This allows use of freezing() in freeze_task().  Replace the open
      coded tests with freezing().
    
    * p != current test is added to warning printing conditions in
      try_to_freeze_tasks() failure path.  This is necessary as freezing()
      is now true for the task which initiated freezing too.
    
    -v2: Oleg pointed out that re-freezing FROZEN cgroup could increment
         system_freezing_cnt.  Fixed.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Paul Menage <paul@paulmenage.org>  (for the cgroup portions)
  7. freezer: clean up freeze_processes() failure path

    Tejun Heo authored
    freeze_processes() failure path is rather messy.  Freezing is canceled
    for workqueues and tasks which aren't frozen yet but frozen tasks are
    left alone and should be thawed by the caller and of course some
    callers (xen and kexec) didn't do it.
    
    This patch updates __thaw_task() to handle cancelation correctly and
    makes freeze_processes() and freeze_kernel_threads() call
    thaw_processes() on failure instead so that the system is fully thawed
    on failure.  Unnecessary [suspend_]thaw_processes() calls are removed
    from kernel/power/hibernate.c, suspend.c and user.c.
    
    While at it, restructure error checking if clause in suspend_prepare()
    to be less weird.
    
    -v2: Srivatsa spotted missing removal of suspend_thaw_processes() in
         suspend_prepare() and error in commit message.  Updated.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
  8. freezer: kill PF_FREEZING

    Tejun Heo authored
    With the previous changes, there's no meaningful difference between
    PF_FREEZING and PF_FROZEN.  Remove PF_FREEZING and use PF_FROZEN
    instead in task_contributes_to_load().
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
  9. freezer: test freezable conditions while holding freezer_lock

    Tejun Heo authored
    try_to_freeze_tasks() and thaw_processes() use freezable() and
    frozen() as preliminary tests before initiating operations on a task.
    These are done without any synchronization and hinder with
    synchronization cleanup without any real performance benefits.
    
    In try_to_freeze_tasks(), open code self test and move PF_NOFREEZE and
    frozen() tests inside freezer_lock in freeze_task().
    
    thaw_processes() can simply drop freezable() test as frozen() test in
    __thaw_task() is enough.
    
    Note: This used to be a part of larger patch to fix set_freezable()
          race.  Separated out to satisfy ordering among dependent fixes.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
  10. freezer: make freezing indicate freeze condition in effect

    Tejun Heo authored
    Currently freezing (TIF_FREEZE) and frozen (PF_FROZEN) states are
    interlocked - freezing is set to request freeze and when the task
    actually freezes, it clears freezing and sets frozen.
    
    This interlocking makes things more complex than necessary - freezing
    doesn't mean there's freezing condition in effect and frozen doesn't
    match the task actually entering and leaving frozen state (it's
    cleared by the thawing task).
    
    This patch makes freezing indicate that freeze condition is in effect.
    A task enters and stays frozen if freezing.  This makes PF_FROZEN
    manipulation done only by the task itself and prevents wakeup from
    __thaw_task() leaking outside of refrigerator.
    
    The only place which needs to tell freezing && !frozen is
    try_to_freeze_task() to whine about tasks which don't enter frozen.
    It's updated to test the condition explicitly.
    
    With the change, frozen() state my linger after __thaw_task() until
    the task wakes up and exits fridge.  This can trigger BUG_ON() in
    update_if_frozen().  Work it around by testing freezing() && frozen()
    instead of frozen().
    
    -v2: Oleg pointed out missing re-check of freezing() when trying to
         clear FROZEN and possible spurious BUG_ON() trigger in
         update_if_frozen().  Both fixed.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Paul Menage <paul@paulmenage.org>
  11. freezer: use dedicated lock instead of task_lock() + memory barrier

    Tejun Heo authored
    Freezer synchronization is needlessly complicated - it's by no means a
    hot path and the priority is staying unintrusive and safe.  This patch
    makes it simply use a dedicated lock instead of piggy-backing on
    task_lock() and playing with memory barriers.
    
    On the failure path of try_to_freeze_tasks(), locking is moved from it
    to cancel_freezing().  This makes the frozen() test racy but the race
    here is a non-issue as the warning is printed for tasks which failed
    to enter frozen for 20 seconds and race on PF_FROZEN at the last
    moment doesn't change anything.
    
    This simplifies freezer implementation and eases further changes
    including some race fixes.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
  12. freezer: rename thaw_process() to __thaw_task() and simplify the impl…

    Tejun Heo authored
    …ementation
    
    thaw_process() now has only internal users - system and cgroup
    freezers.  Remove the unnecessary return value, rename, unexport and
    collapse __thaw_process() into it.  This will help further updates to
    the freezer code.
    
    -v3: oom_kill grew a use of thaw_process() while this patch was
         pending.  Convert it to use __thaw_task() for now.  In the longer
         term, this should be handled by allowing tasks to die if killed
         even if it's frozen.
    
    -v2: minor style update as suggested by Matt.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Paul Menage <menage@google.com>
    Cc: Matt Helsley <matthltc@us.ibm.com>
  13. freezer: implement and use kthread_freezable_should_stop()

    Tejun Heo authored
    Writeback and thinkpad_acpi have been using thaw_process() to prevent
    deadlock between the freezer and kthread_stop(); unfortunately, this
    is inherently racy - nothing prevents freezing from happening between
    thaw_process() and kthread_stop().
    
    This patch implements kthread_freezable_should_stop() which enters
    refrigerator if necessary but is guaranteed to return if
    kthread_stop() is invoked.  Both thaw_process() users are converted to
    use the new function.
    
    Note that this deadlock condition exists for many of freezable
    kthreads.  They need to be converted to use the new should_stop or
    freezable workqueue.
    
    Tested with synthetic test case.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Oleg Nesterov <oleg@redhat.com>
  14. freezer: unexport refrigerator() and update try_to_freeze() slightly

    Tejun Heo authored
    There is no reason to export two functions for entering the
    refrigerator.  Calling refrigerator() instead of try_to_freeze()
    doesn't save anything noticeable or removes any race condition.
    
    * Rename refrigerator() to __refrigerator() and make it return bool
      indicating whether it scheduled out for freezing.
    
    * Update try_to_freeze() to return bool and relay the return value of
      __refrigerator() if freezing().
    
    * Convert all refrigerator() users to try_to_freeze().
    
    * Update documentation accordingly.
    
    * While at it, add might_sleep() to try_to_freeze().
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Samuel Ortiz <samuel@sortiz.org>
    Cc: Chris Mason <chris.mason@oracle.com>
    Cc: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Steven Whitehouse <swhiteho@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jan Kara <jack@suse.cz>
    Cc: KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
    Cc: Christoph Hellwig <hch@infradead.org>
  15. freezer: fix current->state restoration race in refrigerator()

    Tejun Heo authored
    refrigerator() saves current->state before entering frozen state and
    restores it before returning using __set_current_state(); however,
    this is racy, for example, please consider the following sequence.
    
    	set_current_state(TASK_INTERRUPTIBLE);
    	try_to_freeze();
    	if (kthread_should_stop())
    		break;
    	schedule();
    
    If kthread_stop() races with ->state restoration, the restoration can
    restore ->state to TASK_INTERRUPTIBLE after kthread_stop() sets it to
    TASK_RUNNING but kthread_should_stop() may still see zero
    ->should_stop because there's no memory barrier between restoring
    TASK_INTERRUPTIBLE and kthread_should_stop() test.
    
    This isn't restricted to kthread_should_stop().  current->state is
    often used in memory barrier based synchronization and silently
    restoring it w/o mb breaks them.
    
    Use set_current_state() instead.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
Commits on Nov 7, 2011
  1. Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/li…

    authored
    …nux/kernel/git/paulg/linux
    
    * 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
      Revert "tracing: Include module.h in define_trace.h"
      irq: don't put module.h into irq.h for tracking irqgen modules.
      bluetooth: macroize two small inlines to avoid module.h
      ip_vs.h: fix implicit use of module_get/module_put from module.h
      nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
      include: replace linux/module.h with "struct module" wherever possible
      include: convert various register fcns to macros to avoid include chaining
      crypto.h: remove unused crypto_tfm_alg_modname() inline
      uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
      pm_runtime.h: explicitly requires notifier.h
      linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
      miscdevice.h: fix up implicit use of lists and types
      stop_machine.h: fix implicit use of smp.h for smp_processor_id
      of: fix implicit use of errno.h in include/linux/of.h
      of_platform.h: delete needless include <linux/module.h>
      acpi: remove module.h include from platform/aclinux.h
      miscdevice.h: delete unnecessary inclusion of module.h
      device_cgroup.h: delete needless include <linux/module.h>
      net: sch_generic remove redundant use of <linux/module.h>
      net: inet_timewait_sock doesnt need <linux/module.h>
      ...
    
    Fix up trivial conflicts (other header files, and  removal of the ab3550 mfd driver) in
     - drivers/media/dvb/frontends/dibx000_common.c
     - drivers/media/video/{mt9m111.c,ov6650.c}
     - drivers/mfd/ab3550-core.c
     - include/linux/dmaengine.h
Commits on Nov 4, 2011
  1. Rafael J. Wysocki

    PM / Freezer: Revert 2792065 "PM / Freezer: Make fake_signal_wake_up(…

    Tejun Heo authored rjwysocki committed
    …) wake TASK_KILLABLE tasks too"
    
    Commit 2792065 "PM / Freezer: Make fake_signal_wake_up() wake
    TASK_KILLABLE tasks too" updated fake_signal_wake_up() used by freezer
    to wake up KILLABLE tasks.  Sending unsolicited wakeups to tasks in
    killable sleep is dangerous as there are code paths which depend on
    tasks not waking up spuriously from KILLABLE sleep.
    
    For example. sys_read() or page can sleep in TASK_KILLABLE assuming
    that wait/down/whatever _killable can only fail if we can not return
    to the usermode.  TASK_TRACED is another obvious example.
    
    The previous patch updated wait_event_freezekillable() such that it
    doesn't depend on the spurious wakeup.  This patch reverts the
    offending commit.
    
    Note that the spurious KILLABLE wakeup had other implicit effects in
    KILLABLE sleeps in nfs and cifs and those will need further updates to
    regain freezekillable behavior.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Commits on Oct 31, 2011
  1. kernel: Map most files to use export.h instead of module.h

    Paul Gortmaker authored
    The changed files were only including linux/module.h for the
    EXPORT_SYMBOL infrastructure, and nothing else.  Revector them
    onto the isolated export header for faster compile times.
    
    Nothing to see here but a whole lot of instances of:
    
      -#include <linux/module.h>
      +#include <linux/export.h>
    
    This commit is only changing the kernel dir; next targets
    will probably be mm, fs, the arch dirs, etc.
    
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Commits on Oct 16, 2011
  1. Rafael J. Wysocki

    PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too

    Jeff Layton authored rjwysocki committed
    TASK_KILLABLE is often used to put tasks to sleep for quite some time.
    One of the most common uses is to put tasks to sleep while waiting for
    replies from a server on a networked filesystem (such as CIFS or NFS).
    
    Unfortunately, fake_signal_wake_up does not currently wake up tasks
    that are sleeping in TASK_KILLABLE state. This means that even if the
    code were in place to allow them to freeze while in this sleep, it
    wouldn't work anyway.
    
    This patch changes this function to wake tasks in this state as well.
    This should be harmless -- if the code doing the sleeping doesn't have
    handling to deal with freezer events, it should just go back to sleep.
    If it does, then this will allow that code to do the right thing.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Commits on May 17, 2011
  1. Mike Frysinger Rafael J. Wysocki

    Freezer: Use SMP barriers

    vapier authored rjwysocki committed
    The freezer processes are dealing with multiple threads running
    simultaneously, and on a UP system, the memory reads/writes do
    not need barriers to keep things in sync.  These are only needed
    on SMP systems, so use SMP barriers instead.
    
    Signed-off-by: Mike Frysinger <vapier@gentoo.org>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Commits on Dec 24, 2010
  1. Rafael J. Wysocki

    Freezer: Fix a race during freezing of TASK_STOPPED tasks

    Tejun Heo authored rjwysocki committed
    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>
Commits on Jul 18, 2009
  1. sched: fix nr_uninterruptible accounting of frozen tasks really

    Thomas Gleixner authored
    commit e3c8ca8 (sched: do not count frozen tasks toward load) broke
    the nr_uninterruptible accounting on freeze/thaw. On freeze the task
    is excluded from accounting with a check for (task->flags &
    PF_FROZEN), but that flag is cleared before the task is thawed. So
    while we prevent that the task with state TASK_UNINTERRUPTIBLE
    is accounted to nr_uninterruptible on freeze we decrement
    nr_uninterruptible on thaw.
    
    Use a separate flag which is handled by the freezing task itself. Set
    it before calling the scheduler with TASK_UNINTERRUPTIBLE state and
    clear it after we return from frozen state.
    
    Cc: <stable@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Commits on Oct 30, 2008
  1. freezer_cg: use thaw_process() in unfreeze_cgroup()

    Li Zefan authored committed
    Don't duplicate the implementation of thaw_process().
    
    [akpm@linux-foundation.org: make __thaw_process() static]
    Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
    Cc: Cedric Le Goater <clg@fr.ibm.com>
    Acked-by: Matt Helsley <matthltc@us.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commits on Oct 20, 2008
  1. container freezer: implement freezer cgroup subsystem

    Matt Helsley authored committed
    This patch implements a new freezer subsystem in the control groups
    framework.  It provides a way to stop and resume execution of all tasks in
    a cgroup by writing in the cgroup filesystem.
    
    The freezer subsystem in the container filesystem defines a file named
    freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
    in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
    the cgroup.  Reading will return the current state.
    
    * Examples of usage :
    
       # mkdir /containers/freezer
       # mount -t cgroup -ofreezer freezer  /containers
       # mkdir /containers/0
       # echo $some_pid > /containers/0/tasks
    
    to get status of the freezer subsystem :
    
       # cat /containers/0/freezer.state
       RUNNING
    
    to freeze all tasks in the container :
    
       # echo FROZEN > /containers/0/freezer.state
       # cat /containers/0/freezer.state
       FREEZING
       # cat /containers/0/freezer.state
       FROZEN
    
    to unfreeze all tasks in the container :
    
       # echo RUNNING > /containers/0/freezer.state
       # cat /containers/0/freezer.state
       RUNNING
    
    This is the basic mechanism which should do the right thing for user space
    task in a simple scenario.
    
    It's important to note that freezing can be incomplete.  In that case we
    return EBUSY.  This means that some tasks in the cgroup are busy doing
    something that prevents us from completely freezing the cgroup at this
    time.  After EBUSY, the cgroup will remain partially frozen -- reflected
    by freezer.state reporting "FREEZING" when read.  The state will remain
    "FREEZING" until one of these things happens:
    
    	1) Userspace cancels the freezing operation by writing "RUNNING" to
    		the freezer.state file
    	2) Userspace retries the freezing operation by writing "FROZEN" to
    		the freezer.state file (writing "FREEZING" is not legal
    		and returns EIO)
    	3) The tasks that blocked the cgroup from entering the "FROZEN"
    		state disappear from the cgroup's set of tasks.
    
    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: export thaw_process]
    Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
    Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
    Acked-by: Serge E. Hallyn <serue@us.ibm.com>
    Tested-by: Matt Helsley <matthltc@us.ibm.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  2. container freezer: make refrigerator always available

    Matt Helsley authored committed
    Now that the TIF_FREEZE flag is available in all architectures, extract
    the refrigerator() and freeze_task() from kernel/power/process.c and make
    it available to all.
    
    The refrigerator() can now be used in a control group subsystem
    implementing a control group freezer.
    
    Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
    Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
    Acked-by: Serge E. Hallyn <serue@us.ibm.com>
    Tested-by: Matt Helsley <matthltc@us.ibm.com>
    Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Something went wrong with that request. Please try again.