Container Freezer v6: Reuse Suspend Freezer

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 <[email protected]>

Signed-off-by Matt Helsley <[email protected]>

Acked-by Serge E. Hallyn <[email protected]>

Tested-by Matt Helsley <[email protected]>

---

kernel/power/Kconfig +0 -0

 config SUSPEND
 	bool "Suspend to RAM and standby"
 	depends on PM && ARCH_SUSPEND_POSSIBLE

Quoted 7 lines · Matt Helsley

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.

Quoted 4 lines

Signed-off-by Cedric Le Goater <clg-NmTC/[email protected]>

Signed-off-by Matt Helsley <matthltc-r/[email protected]>

Acked-by Serge E. Hallyn <serue-r/[email protected]>

Tested-by Matt Helsley <matthltc-r/[email protected]>

Your Signed-off-by implies your Tested-by (at least it should ;-)).

Quoted 1 line

---

[--snip--]

Quoted 8 lines

Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
===================================================================

kernel/power/Kconfig +0 -0

@@ -85,6 +85,9 @@ config PM_SLEEP
 	depends on SUSPEND || HIBERNATION || XEN_SAVE_RESTORE
 	default y
 

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 3 lines

kernel/power/Kconfig +3 -0

+config FREEZER
+	def_bool PM_SLEEP
+

I'd still prefer this to go into a Kconfig in the parent directory (ie. where freezer.c and the Makefile building it are located). Otherwise it's guaranteed to confuse someone.

Quoted 7 lines · Matt Helsley

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.

Quoted 4 lines

Signed-off-by Cedric Le Goater <[email protected]>

Signed-off-by Matt Helsley <[email protected]>

Acked-by Serge E. Hallyn <[email protected]>

Tested-by Matt Helsley <[email protected]>

Your Signed-off-by implies your Tested-by (at least it should ;-)).

Quoted 1 line

---

[--snip--]

Quoted 8 lines

Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
===================================================================

kernel/power/Kconfig +0 -0

@@ -85,6 +85,9 @@ config PM_SLEEP
 	depends on SUSPEND || HIBERNATION || XEN_SAVE_RESTORE
 	default y
 

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 3 lines

kernel/power/Kconfig +3 -0

+config FREEZER
+	def_bool PM_SLEEP
+

I'd still prefer this to go into a Kconfig in the parent directory (ie. where freezer.c and the Makefile building it are located). Otherwise it's guaranteed to confuse someone.

Quoted 7 lines · Matt Helsley

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.

Quoted 4 lines

Signed-off-by Cedric Le Goater <[email protected]>

Signed-off-by Matt Helsley <[email protected]>

Acked-by Serge E. Hallyn <[email protected]>

Tested-by Matt Helsley <[email protected]>

Your Signed-off-by implies your Tested-by (at least it should ;-)).

Quoted 1 line

---

[--snip--]

Quoted 8 lines

Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
===================================================================

kernel/power/Kconfig +0 -0

@@ -85,6 +85,9 @@ config PM_SLEEP
 	depends on SUSPEND || HIBERNATION || XEN_SAVE_RESTORE
 	default y
 

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 3 lines

kernel/power/Kconfig +3 -0

+config FREEZER
+	def_bool PM_SLEEP
+

I'd still prefer this to go into a Kconfig in the parent directory (ie. where freezer.c and the Makefile building it are located). Otherwise it's guaranteed to confuse someone.

Quoted 8 lines · Rafael J. Wysocki

Quoted 7 lines · Matt Helsley

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.

Quoted 6 lines

Quoted 4 lines

Signed-off-by Cedric Le Goater <clg-NmTC/[email protected]>

Signed-off-by Matt Helsley <matthltc-r/[email protected]>

Acked-by Serge E. Hallyn <serue-r/[email protected]>

Tested-by Matt Helsley <matthltc-r/[email protected]>

Your Signed-off-by implies your Tested-by (at least it should ;-)).

I wasn't sure that was always true so I added it just in case. I'll take it out of any future postings.

Quoted 10 lines

Quoted 1 line

---

[--snip--]

Quoted 8 lines

Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
===================================================================

kernel/power/Kconfig +0 -0

@@ -85,6 +85,9 @@ config PM_SLEEP
 	depends on SUSPEND || HIBERNATION || XEN_SAVE_RESTORE
 	default y
 

Quoted 7 lines

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 3 lines

kernel/power/Kconfig +3 -0

+config FREEZER
+	def_bool PM_SLEEP
+

I'd still prefer this to go into a Kconfig in the parent directory (ie. where freezer.c and the Makefile building it are located). Otherwise it's guaranteed to confuse someone.

I'm thinking of making a patch moving the cgroups config variables into
a kernel/Kconfig.cgroups file. Would moving config FREEZER to such a file be satisfactory? Paul, what do you think?

Quoted 8 lines · Rafael J. Wysocki

Quoted 7 lines · Matt Helsley

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.

Quoted 6 lines

Quoted 4 lines

Signed-off-by Cedric Le Goater <[email protected]>

Signed-off-by Matt Helsley <[email protected]>

Acked-by Serge E. Hallyn <[email protected]>

Tested-by Matt Helsley <[email protected]>

Your Signed-off-by implies your Tested-by (at least it should ;-)).

I wasn't sure that was always true so I added it just in case. I'll take it out of any future postings.

Quoted 10 lines

Quoted 1 line

---

[--snip--]

Quoted 8 lines

Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
===================================================================

kernel/power/Kconfig +0 -0

@@ -85,6 +85,9 @@ config PM_SLEEP
 	depends on SUSPEND || HIBERNATION || XEN_SAVE_RESTORE
 	default y
 

Quoted 7 lines

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 3 lines

kernel/power/Kconfig +3 -0

+config FREEZER
+	def_bool PM_SLEEP
+

I'd still prefer this to go into a Kconfig in the parent directory (ie. where freezer.c and the Makefile building it are located). Otherwise it's guaranteed to confuse someone.

I'm thinking of making a patch moving the cgroups config variables into
a kernel/Kconfig.cgroups file. Would moving config FREEZER to such a file be satisfactory? Paul, what do you think?

Quoted 8 lines · Rafael J. Wysocki

Quoted 7 lines · Matt Helsley

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.

Quoted 6 lines

Quoted 4 lines

Signed-off-by Cedric Le Goater <[email protected]>

Signed-off-by Matt Helsley <[email protected]>

Acked-by Serge E. Hallyn <[email protected]>

Tested-by Matt Helsley <[email protected]>

Your Signed-off-by implies your Tested-by (at least it should ;-)).

I wasn't sure that was always true so I added it just in case. I'll take it out of any future postings.

Quoted 10 lines

Quoted 1 line

---

[--snip--]

Quoted 8 lines

Index: linux-2.6.27-rc1-mm1/kernel/power/Kconfig
===================================================================

kernel/power/Kconfig +0 -0

@@ -85,6 +85,9 @@ config PM_SLEEP
 	depends on SUSPEND || HIBERNATION || XEN_SAVE_RESTORE
 	default y
 

Quoted 7 lines

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 3 lines

kernel/power/Kconfig +3 -0

+config FREEZER
+	def_bool PM_SLEEP
+

I'd still prefer this to go into a Kconfig in the parent directory (ie. where freezer.c and the Makefile building it are located). Otherwise it's guaranteed to confuse someone.

I'm thinking of making a patch moving the cgroups config variables into
a kernel/Kconfig.cgroups file. Would moving config FREEZER to such a file be satisfactory? Paul, what do you think?

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-NmTC/[email protected]>

Signed-off-by Matt Helsley <matthltc-r/[email protected]>

Acked-by Serge E. Hallyn <serue-r/[email protected]>

Tested-by Matt Helsley <matthltc-r/[email protected]>

---

kernel/power/Kconfig +0 -0

 config SUSPEND
 	bool "Suspend to RAM and standby"
 	depends on PM && ARCH_SUSPEND_POSSIBLE

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 <[email protected]>

Signed-off-by Matt Helsley <[email protected]>

Acked-by Serge E. Hallyn <[email protected]>

Tested-by Matt Helsley <[email protected]>

---

kernel/power/Kconfig +0 -0

 config SUSPEND
 	bool "Suspend to RAM and standby"
 	depends on PM && ARCH_SUSPEND_POSSIBLE

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.

...

include/linux/cgroup_subsys.h +6 -0

+
+#ifdef CONFIG_CGROUP_FREEZER
+SUBSYS(freezer)
+#endif
+
+/* */

Index: linux-2.6.27-rc1-mm1/include/linux/freezer.h
===================================================================

include/linux/freezer.h +10 -3

@@ -47,22 +47,30 @@ static inline bool should_send_signal(st
 /*
  * Wake up a frozen process
  *
- * task_lock() is taken to prevent the race with refrigerator() which may
+ * task_lock() is needed to prevent the race with refrigerator() which may
  * occur if the freezing of tasks fails.  Namely, without the lock, if the
  * freezing of tasks failed, thaw_tasks() might have run before a task in
  * refrigerator() could call frozen_process(), in which case the task would be
  * frozen and no one would thaw it.
  */
-static inline int thaw_process(struct task_struct *p)
+static inline int __thaw_process(struct task_struct *p)
 {
-	task_lock(p);
 	if (frozen(p)) {
 		p->flags &= ~PF_FROZEN;
+		return 1;
+	}
+	clear_freeze_flag(p);
+	return 0;
+}
+
+static inline int thaw_process(struct task_struct *p)
+{

include/linux/freezer.h +6 -0

@@ -83,6 +91,12 @@ static inline int try_to_freeze(void)
 extern bool freeze_task(struct task_struct *p, bool sig_only);
 extern void cancel_freezing(struct task_struct *p);
 
+#ifdef CONFIG_CGROUP_FREEZER
+extern int cgroup_frozen(struct task_struct *task);
+#else /* !CONFIG_CGROUP_FREEZER */
+static inline int cgroup_frozen(struct task_struct *task) { return 0; }
+#endif /* !CONFIG_CGROUP_FREEZER */
+
 /*
  * The PF_FREEZER_SKIP flag should be set by a vfork parent right before it
  * calls wait_for_completion(&vfork) and reset right after it returns from this

Index: linux-2.6.27-rc1-mm1/init/Kconfig
===================================================================

kernel/power/Kconfig +4 -0

+        help
+          Provides a way to freeze and unfreeze all tasks in a
+	  cgroup.
+
 config CGROUP_DEVICE
 	bool "Device controller for cgroups"
 	depends on CGROUPS && EXPERIMENTAL

Index: linux-2.6.27-rc1-mm1/kernel/Makefile
===================================================================

kernel/Makefile +1 -0

@@ -54,6 +54,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
 obj-$(CONFIG_CGROUP_DEBUG) += cgroup_debug.o
+obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_CGROUP_NS) += ns_cgroup.o
 obj-$(CONFIG_UTS_NS) += utsname.o

Index: linux-2.6.27-rc1-mm1/kernel/cgroup_freezer.c
===================================================================

kernel/cgroup_freezer.c new file +15 -0

@@ -0,0 +1,366 @@
+/*
+ * cgroup_freezer.c -  control group freezer subsystem
+ *
+ * Copyright IBM Corporation, 2007
+ *
+ * Author : Cedric Le Goater <clg-NmTC/[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */

kernel/cgroup_freezer.c new file +31 -0

+	STATE_FREEZING,
+	STATE_FROZEN,
+};
+
+struct freezer {
+	struct cgroup_subsys_state css;
+	enum freezer_state state;
+	spinlock_t lock; /* protects _writes_ to state */
+};
+
+static inline struct freezer *cgroup_freezer(
+		struct cgroup *cgroup)
+{
+	return container_of(
+		cgroup_subsys_state(cgroup, freezer_subsys_id),
+		struct freezer, css);
+}
+
+static inline struct freezer *task_freezer(struct task_struct *task)
+{
+	return container_of(task_subsys_state(task, freezer_subsys_id),
+			    struct freezer, css);
+}
+
+int cgroup_frozen(struct task_struct *task)
+{
+	struct freezer *freezer;
+	enum freezer_state state;
+
+	task_lock(task);
+	freezer = task_freezer(task);

kernel/cgroup_freezer.c new file +5 -0

+static const char *freezer_state_strs[] = {
+	"RUNNING",
+	"FREEZING",
+	"FROZEN",
+};

kernel/cgroup_freezer.c new file +27 -0

+{
+	struct cgroup_iter it;
+	struct task_struct *task;
+	unsigned int nfrozen = 0, ntotal = 0;
+
+	cgroup_iter_start(cgroup, &it);
+	while ((task = cgroup_iter_next(cgroup, &it))) {
+		ntotal++;
+		/*
+		 * Task is frozen or will freeze immediately when next it gets
+		 * woken
+		 */
+		if (frozen(task) ||
+		    (task_is_stopped_or_traced(task) && freezing(task)))
+			nfrozen++;
+	}
+
+	/*
+	 * Transition to FROZEN when no new tasks can be added ensures
+	 * that we never exist in the FROZEN state while there are unfrozen
+	 * tasks.
+	 */
+	if (nfrozen == ntotal)
+		freezer->state = STATE_FROZEN;
+	cgroup_iter_end(cgroup, &it);
+}
+
 

kernel/cgroup_freezer.c new file +13 -0

+		goal_state = STATE_RUNNING;
+	else if (strcmp(buffer, freezer_state_strs[STATE_FROZEN]) == 0)
+		goal_state = STATE_FROZEN;
+	else
+		return -EIO;
+
+	if (!cgroup_lock_live_group(cgroup))
+		return -ENODEV;
+	retval = freezer_change_state(cgroup, goal_state);
+	cgroup_unlock();
+	return retval;
+}
+
 
...

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.

...

include/linux/cgroup_subsys.h +6 -0

+
+#ifdef CONFIG_CGROUP_FREEZER
+SUBSYS(freezer)
+#endif
+
+/* */

Index: linux-2.6.27-rc1-mm1/include/linux/freezer.h
===================================================================

include/linux/freezer.h +10 -3

@@ -47,22 +47,30 @@ static inline bool should_send_signal(st
 /*
  * Wake up a frozen process
  *
- * task_lock() is taken to prevent the race with refrigerator() which may
+ * task_lock() is needed to prevent the race with refrigerator() which may
  * occur if the freezing of tasks fails.  Namely, without the lock, if the
  * freezing of tasks failed, thaw_tasks() might have run before a task in
  * refrigerator() could call frozen_process(), in which case the task would be
  * frozen and no one would thaw it.
  */
-static inline int thaw_process(struct task_struct *p)
+static inline int __thaw_process(struct task_struct *p)
 {
-	task_lock(p);
 	if (frozen(p)) {
 		p->flags &= ~PF_FROZEN;
+		return 1;
+	}
+	clear_freeze_flag(p);
+	return 0;
+}
+
+static inline int thaw_process(struct task_struct *p)
+{

include/linux/freezer.h +6 -0

@@ -83,6 +91,12 @@ static inline int try_to_freeze(void)
 extern bool freeze_task(struct task_struct *p, bool sig_only);
 extern void cancel_freezing(struct task_struct *p);
 
+#ifdef CONFIG_CGROUP_FREEZER
+extern int cgroup_frozen(struct task_struct *task);
+#else /* !CONFIG_CGROUP_FREEZER */
+static inline int cgroup_frozen(struct task_struct *task) { return 0; }
+#endif /* !CONFIG_CGROUP_FREEZER */
+
 /*
  * The PF_FREEZER_SKIP flag should be set by a vfork parent right before it
  * calls wait_for_completion(&vfork) and reset right after it returns from this

Index: linux-2.6.27-rc1-mm1/init/Kconfig
===================================================================

kernel/power/Kconfig +4 -0

+        help
+          Provides a way to freeze and unfreeze all tasks in a
+	  cgroup.
+
 config CGROUP_DEVICE
 	bool "Device controller for cgroups"
 	depends on CGROUPS && EXPERIMENTAL

Index: linux-2.6.27-rc1-mm1/kernel/Makefile
===================================================================

kernel/Makefile +1 -0

@@ -54,6 +54,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
 obj-$(CONFIG_CGROUP_DEBUG) += cgroup_debug.o
+obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_CGROUP_NS) += ns_cgroup.o
 obj-$(CONFIG_UTS_NS) += utsname.o

Index: linux-2.6.27-rc1-mm1/kernel/cgroup_freezer.c
===================================================================

kernel/cgroup_freezer.c new file +15 -0

@@ -0,0 +1,366 @@
+/*
+ * cgroup_freezer.c -  control group freezer subsystem
+ *
+ * Copyright IBM Corporation, 2007
+ *
+ * Author : Cedric Le Goater <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */

kernel/cgroup_freezer.c new file +31 -0

+	STATE_FREEZING,
+	STATE_FROZEN,
+};
+
+struct freezer {
+	struct cgroup_subsys_state css;
+	enum freezer_state state;
+	spinlock_t lock; /* protects _writes_ to state */
+};
+
+static inline struct freezer *cgroup_freezer(
+		struct cgroup *cgroup)
+{
+	return container_of(
+		cgroup_subsys_state(cgroup, freezer_subsys_id),
+		struct freezer, css);
+}
+
+static inline struct freezer *task_freezer(struct task_struct *task)
+{
+	return container_of(task_subsys_state(task, freezer_subsys_id),
+			    struct freezer, css);
+}
+
+int cgroup_frozen(struct task_struct *task)
+{
+	struct freezer *freezer;
+	enum freezer_state state;
+
+	task_lock(task);
+	freezer = task_freezer(task);

kernel/cgroup_freezer.c new file +5 -0

+static const char *freezer_state_strs[] = {
+	"RUNNING",
+	"FREEZING",
+	"FROZEN",
+};

kernel/cgroup_freezer.c new file +27 -0

+{
+	struct cgroup_iter it;
+	struct task_struct *task;
+	unsigned int nfrozen = 0, ntotal = 0;
+
+	cgroup_iter_start(cgroup, &it);
+	while ((task = cgroup_iter_next(cgroup, &it))) {
+		ntotal++;
+		/*
+		 * Task is frozen or will freeze immediately when next it gets
+		 * woken
+		 */
+		if (frozen(task) ||
+		    (task_is_stopped_or_traced(task) && freezing(task)))
+			nfrozen++;
+	}
+
+	/*
+	 * Transition to FROZEN when no new tasks can be added ensures
+	 * that we never exist in the FROZEN state while there are unfrozen
+	 * tasks.
+	 */
+	if (nfrozen == ntotal)
+		freezer->state = STATE_FROZEN;
+	cgroup_iter_end(cgroup, &it);
+}
+
 

kernel/cgroup_freezer.c new file +13 -0

+		goal_state = STATE_RUNNING;
+	else if (strcmp(buffer, freezer_state_strs[STATE_FROZEN]) == 0)
+		goal_state = STATE_FROZEN;
+	else
+		return -EIO;
+
+	if (!cgroup_lock_live_group(cgroup))
+		return -ENODEV;
+	retval = freezer_change_state(cgroup, goal_state);
+	cgroup_unlock();
+	return retval;
+}
+
 
...

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.

...

include/linux/cgroup_subsys.h +6 -0

+
+#ifdef CONFIG_CGROUP_FREEZER
+SUBSYS(freezer)
+#endif
+
+/* */

Index: linux-2.6.27-rc1-mm1/include/linux/freezer.h
===================================================================

include/linux/freezer.h +10 -3

@@ -47,22 +47,30 @@ static inline bool should_send_signal(st
 /*
  * Wake up a frozen process
  *
- * task_lock() is taken to prevent the race with refrigerator() which may
+ * task_lock() is needed to prevent the race with refrigerator() which may
  * occur if the freezing of tasks fails.  Namely, without the lock, if the
  * freezing of tasks failed, thaw_tasks() might have run before a task in
  * refrigerator() could call frozen_process(), in which case the task would be
  * frozen and no one would thaw it.
  */
-static inline int thaw_process(struct task_struct *p)
+static inline int __thaw_process(struct task_struct *p)
 {
-	task_lock(p);
 	if (frozen(p)) {
 		p->flags &= ~PF_FROZEN;
+		return 1;
+	}
+	clear_freeze_flag(p);
+	return 0;
+}
+
+static inline int thaw_process(struct task_struct *p)
+{

include/linux/freezer.h +6 -0

@@ -83,6 +91,12 @@ static inline int try_to_freeze(void)
 extern bool freeze_task(struct task_struct *p, bool sig_only);
 extern void cancel_freezing(struct task_struct *p);
 
+#ifdef CONFIG_CGROUP_FREEZER
+extern int cgroup_frozen(struct task_struct *task);
+#else /* !CONFIG_CGROUP_FREEZER */
+static inline int cgroup_frozen(struct task_struct *task) { return 0; }
+#endif /* !CONFIG_CGROUP_FREEZER */
+
 /*
  * The PF_FREEZER_SKIP flag should be set by a vfork parent right before it
  * calls wait_for_completion(&vfork) and reset right after it returns from this

Index: linux-2.6.27-rc1-mm1/init/Kconfig
===================================================================

kernel/power/Kconfig +4 -0

+        help
+          Provides a way to freeze and unfreeze all tasks in a
+	  cgroup.
+
 config CGROUP_DEVICE
 	bool "Device controller for cgroups"
 	depends on CGROUPS && EXPERIMENTAL

Index: linux-2.6.27-rc1-mm1/kernel/Makefile
===================================================================

kernel/Makefile +1 -0

@@ -54,6 +54,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
 obj-$(CONFIG_CGROUP_DEBUG) += cgroup_debug.o
+obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_CGROUP_NS) += ns_cgroup.o
 obj-$(CONFIG_UTS_NS) += utsname.o

Index: linux-2.6.27-rc1-mm1/kernel/cgroup_freezer.c
===================================================================

kernel/cgroup_freezer.c new file +15 -0

@@ -0,0 +1,366 @@
+/*
+ * cgroup_freezer.c -  control group freezer subsystem
+ *
+ * Copyright IBM Corporation, 2007
+ *
+ * Author : Cedric Le Goater <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */

kernel/cgroup_freezer.c new file +31 -0

+	STATE_FREEZING,
+	STATE_FROZEN,
+};
+
+struct freezer {
+	struct cgroup_subsys_state css;
+	enum freezer_state state;
+	spinlock_t lock; /* protects _writes_ to state */
+};
+
+static inline struct freezer *cgroup_freezer(
+		struct cgroup *cgroup)
+{
+	return container_of(
+		cgroup_subsys_state(cgroup, freezer_subsys_id),
+		struct freezer, css);
+}
+
+static inline struct freezer *task_freezer(struct task_struct *task)
+{
+	return container_of(task_subsys_state(task, freezer_subsys_id),
+			    struct freezer, css);
+}
+
+int cgroup_frozen(struct task_struct *task)
+{
+	struct freezer *freezer;
+	enum freezer_state state;
+
+	task_lock(task);
+	freezer = task_freezer(task);

kernel/cgroup_freezer.c new file +5 -0

+static const char *freezer_state_strs[] = {
+	"RUNNING",
+	"FREEZING",
+	"FROZEN",
+};

kernel/cgroup_freezer.c new file +27 -0

+{
+	struct cgroup_iter it;
+	struct task_struct *task;
+	unsigned int nfrozen = 0, ntotal = 0;
+
+	cgroup_iter_start(cgroup, &it);
+	while ((task = cgroup_iter_next(cgroup, &it))) {
+		ntotal++;
+		/*
+		 * Task is frozen or will freeze immediately when next it gets
+		 * woken
+		 */
+		if (frozen(task) ||
+		    (task_is_stopped_or_traced(task) && freezing(task)))
+			nfrozen++;
+	}
+
+	/*
+	 * Transition to FROZEN when no new tasks can be added ensures
+	 * that we never exist in the FROZEN state while there are unfrozen
+	 * tasks.
+	 */
+	if (nfrozen == ntotal)
+		freezer->state = STATE_FROZEN;
+	cgroup_iter_end(cgroup, &it);
+}
+
 

kernel/cgroup_freezer.c new file +13 -0

+		goal_state = STATE_RUNNING;
+	else if (strcmp(buffer, freezer_state_strs[STATE_FROZEN]) == 0)
+		goal_state = STATE_FROZEN;
+	else
+		return -EIO;
+
+	if (!cgroup_lock_live_group(cgroup))
+		return -ENODEV;
+	retval = freezer_change_state(cgroup, goal_state);
+	cgroup_unlock();
+	return retval;
+}
+
 
...

Quoted 53 lines · On Mon, 11 Aug 2008 16:53:26 -0700 Matt Helsley…

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.

Quoted 1 line

...

Is a Documentation/ update planned? Documentation/cgroups.txt might be the place, or not.

Quoted 39 lines

include/linux/cgroup_subsys.h +6 -0

+
+#ifdef CONFIG_CGROUP_FREEZER
+SUBSYS(freezer)
+#endif
+
+/* */

Index: linux-2.6.27-rc1-mm1/include/linux/freezer.h
===================================================================

include/linux/freezer.h +12 -3

@@ -47,22 +47,30 @@ static inline bool should_send_signal(st
 /*
  * Wake up a frozen process
  *
- * task_lock() is taken to prevent the race with refrigerator() which may
+ * task_lock() is needed to prevent the race with refrigerator() which may
  * occur if the freezing of tasks fails.  Namely, without the lock, if the
  * freezing of tasks failed, thaw_tasks() might have run before a task in
  * refrigerator() could call frozen_process(), in which case the task would be
  * frozen and no one would thaw it.
  */
-static inline int thaw_process(struct task_struct *p)
+static inline int __thaw_process(struct task_struct *p)
 {
-	task_lock(p);
 	if (frozen(p)) {
 		p->flags &= ~PF_FROZEN;
+		return 1;
+	}
+	clear_freeze_flag(p);
+	return 0;
+}
+
+static inline int thaw_process(struct task_struct *p)
+{
+	task_lock(p);
+	if (__thaw_process(p) == 1) {
 		task_unlock(p);
 		wake_up_process(p);

include/linux/freezer.h static inline bool should_send_signal(st · line 76

Quoted 6 lines

include/linux/freezer.h +0 -1

 		return 1;
 	}
-	clear_freeze_flag(p);
 	task_unlock(p);
 	return 0;
 }

I wonder why these are inlined.

Quoted 18 lines

include/linux/freezer.h +6 -0

@@ -83,6 +91,12 @@ static inline int try_to_freeze(void)
 extern bool freeze_task(struct task_struct *p, bool sig_only);
 extern void cancel_freezing(struct task_struct *p);
 
+#ifdef CONFIG_CGROUP_FREEZER
+extern int cgroup_frozen(struct task_struct *task);
+#else /* !CONFIG_CGROUP_FREEZER */
+static inline int cgroup_frozen(struct task_struct *task) { return 0; }
+#endif /* !CONFIG_CGROUP_FREEZER */
+
 /*
  * The PF_FREEZER_SKIP flag should be set by a vfork parent right before it
  * calls wait_for_completion(&vfork) and reset right after it returns from this

Index: linux-2.6.27-rc1-mm1/init/Kconfig
===================================================================

init/Kconfig config CGROUP_NS · line 304

Quoted 6 lines

init/Kconfig +3 -0

@@ -299,6 +299,13 @@ config CGROUP_NS
           for instance virtual servers and checkpoint/restart
           jobs.
 
+config CGROUP_FREEZER
+        bool "control group freezer subsystem"
+        depends on CGROUPS

Should it depend on FREEZER also?

oh,

Quoted 5 lines

kernel/power/Kconfig +0 -0

@@ -86,7 +86,7 @@ config PM_SLEEP
 	default y
 

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 4 lines

kernel/power/Kconfig +1 -1

 config FREEZER
-	def_bool PM_SLEEP
+	def_bool PM_SLEEP || CGROUP_FREEZER
 

we did it that way. Spose that makes sense.

Quoted 46 lines

kernel/power/Kconfig +4 -0

+        help
+          Provides a way to freeze and unfreeze all tasks in a
+	  cgroup.
+
 config CGROUP_DEVICE
 	bool "Device controller for cgroups"
 	depends on CGROUPS && EXPERIMENTAL

Index: linux-2.6.27-rc1-mm1/kernel/Makefile
===================================================================

kernel/Makefile +1 -0

@@ -54,6 +54,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
 obj-$(CONFIG_CGROUP_DEBUG) += cgroup_debug.o
+obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_CGROUP_NS) += ns_cgroup.o
 obj-$(CONFIG_UTS_NS) += utsname.o

Index: linux-2.6.27-rc1-mm1/kernel/cgroup_freezer.c
===================================================================

kernel/cgroup_freezer.c new file +22 -0

@@ -0,0 +1,366 @@
+/*
+ * cgroup_freezer.c -  control group freezer subsystem
+ *
+ * Copyright IBM Corporation, 2007
+ *
+ * Author : Cedric Le Goater <clg-NmTC/[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include <linux/module.h>
+#include <linux/cgroup.h>
+#include <linux/fs.h>
+#include <linux/uaccess.h>
+#include <linux/freezer.h>
+#include <linux/seq_file.h>

kernel/cgroup_freezer.c line 25

Quoted 3 lines

kernel/cgroup_freezer.c new file +3 -0

+
+enum freezer_state {
+	STATE_RUNNING = 0,

That's a pretty vanilla-sounding identifier. Let's hope this file never ends up including drivers/net/sfc/net_driver.h by some means. That's rather unlikely, but someone could easily choose to implement a new STATE_RUNNING somewhere else.

Quoted 35 lines

kernel/cgroup_freezer.c new file +35 -0

+	STATE_FREEZING,
+	STATE_FROZEN,
+};
+
+struct freezer {
+	struct cgroup_subsys_state css;
+	enum freezer_state state;
+	spinlock_t lock; /* protects _writes_ to state */
+};
+
+static inline struct freezer *cgroup_freezer(
+		struct cgroup *cgroup)
+{
+	return container_of(
+		cgroup_subsys_state(cgroup, freezer_subsys_id),
+		struct freezer, css);
+}
+
+static inline struct freezer *task_freezer(struct task_struct *task)
+{
+	return container_of(task_subsys_state(task, freezer_subsys_id),
+			    struct freezer, css);
+}
+
+int cgroup_frozen(struct task_struct *task)
+{
+	struct freezer *freezer;
+	enum freezer_state state;
+
+	task_lock(task);
+	freezer = task_freezer(task);
+	state = freezer->state;
+	task_unlock(task);
+
+	return state == STATE_FROZEN;

kernel/cgroup_freezer.c line 66

Quoted 6 lines

kernel/cgroup_freezer.c new file +6 -0

+}
+
+/*
+ * Buffer size for freezer state is limited by cgroups write_string()
+ * interface. See cgroups code for the current size.
+ */

Is this comment in the correct place?

Quoted 5 lines

kernel/cgroup_freezer.c new file +5 -0

+static const char *freezer_state_strs[] = {
+	"RUNNING",
+	"FREEZING",
+	"FROZEN",
+};

kernel/cgroup_freezer.c line 187

Quoted 10 lines

kernel/cgroup_freezer.c new file +7 -0

+
 
...
 
+
+/*
+ * caller must hold freezer->lock
+ */
+static void check_if_frozen(struct cgroup *cgroup,
+			     struct freezer *freezer)

check_if_frozen() is an unfortunate name, I suspect. Normally one would expect a check_foo() to return a bool and have no side-effects.

Perhaps some comments explaining what it does would help.

Quoted 30 lines

kernel/cgroup_freezer.c new file +27 -0

+{
+	struct cgroup_iter it;
+	struct task_struct *task;
+	unsigned int nfrozen = 0, ntotal = 0;
+
+	cgroup_iter_start(cgroup, &it);
+	while ((task = cgroup_iter_next(cgroup, &it))) {
+		ntotal++;
+		/*
+		 * Task is frozen or will freeze immediately when next it gets
+		 * woken
+		 */
+		if (frozen(task) ||
+		    (task_is_stopped_or_traced(task) && freezing(task)))
+			nfrozen++;
+	}
+
+	/*
+	 * Transition to FROZEN when no new tasks can be added ensures
+	 * that we never exist in the FROZEN state while there are unfrozen
+	 * tasks.
+	 */
+	if (nfrozen == ntotal)
+		freezer->state = STATE_FROZEN;
+	cgroup_iter_end(cgroup, &it);
+}
+
 
...

kernel/cgroup_freezer.c line 329

Quoted 8 lines

kernel/cgroup_freezer.c new file +8 -0

+static int freezer_write(struct cgroup *cgroup,
+			 struct cftype *cft,
+			 const char *buffer)
+{
+	int retval;
+	enum freezer_state goal_state;
+
+	if (strcmp(buffer, freezer_state_strs[STATE_RUNNING]) == 0)

Did some higher-level code take care of removing the trailing \n?

Quoted 53 lines · On Mon, 11 Aug 2008 16:53:26 -0700 Matt Helsley <[email protected]> wrote:

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.

Quoted 1 line

...

Is a Documentation/ update planned? Documentation/cgroups.txt might be the place, or not.

Quoted 39 lines

include/linux/cgroup_subsys.h +6 -0

+
+#ifdef CONFIG_CGROUP_FREEZER
+SUBSYS(freezer)
+#endif
+
+/* */

Index: linux-2.6.27-rc1-mm1/include/linux/freezer.h
===================================================================

include/linux/freezer.h +12 -3

@@ -47,22 +47,30 @@ static inline bool should_send_signal(st
 /*
  * Wake up a frozen process
  *
- * task_lock() is taken to prevent the race with refrigerator() which may
+ * task_lock() is needed to prevent the race with refrigerator() which may
  * occur if the freezing of tasks fails.  Namely, without the lock, if the
  * freezing of tasks failed, thaw_tasks() might have run before a task in
  * refrigerator() could call frozen_process(), in which case the task would be
  * frozen and no one would thaw it.
  */
-static inline int thaw_process(struct task_struct *p)
+static inline int __thaw_process(struct task_struct *p)
 {
-	task_lock(p);
 	if (frozen(p)) {
 		p->flags &= ~PF_FROZEN;
+		return 1;
+	}
+	clear_freeze_flag(p);
+	return 0;
+}
+
+static inline int thaw_process(struct task_struct *p)
+{
+	task_lock(p);
+	if (__thaw_process(p) == 1) {
 		task_unlock(p);
 		wake_up_process(p);

include/linux/freezer.h static inline bool should_send_signal(st · line 76

Quoted 6 lines

include/linux/freezer.h +0 -1

 		return 1;
 	}
-	clear_freeze_flag(p);
 	task_unlock(p);
 	return 0;
 }

I wonder why these are inlined.

Quoted 18 lines

include/linux/freezer.h +6 -0

@@ -83,6 +91,12 @@ static inline int try_to_freeze(void)
 extern bool freeze_task(struct task_struct *p, bool sig_only);
 extern void cancel_freezing(struct task_struct *p);
 
+#ifdef CONFIG_CGROUP_FREEZER
+extern int cgroup_frozen(struct task_struct *task);
+#else /* !CONFIG_CGROUP_FREEZER */
+static inline int cgroup_frozen(struct task_struct *task) { return 0; }
+#endif /* !CONFIG_CGROUP_FREEZER */
+
 /*
  * The PF_FREEZER_SKIP flag should be set by a vfork parent right before it
  * calls wait_for_completion(&vfork) and reset right after it returns from this

Index: linux-2.6.27-rc1-mm1/init/Kconfig
===================================================================

init/Kconfig config CGROUP_NS · line 304

Quoted 6 lines

init/Kconfig +3 -0

@@ -299,6 +299,13 @@ config CGROUP_NS
           for instance virtual servers and checkpoint/restart
           jobs.
 
+config CGROUP_FREEZER
+        bool "control group freezer subsystem"
+        depends on CGROUPS

Should it depend on FREEZER also?

oh,

Quoted 5 lines

kernel/power/Kconfig +0 -0

@@ -86,7 +86,7 @@ config PM_SLEEP
 	default y
 

kernel/power/Kconfig config PM_SLEEP · line 90

Quoted 4 lines

kernel/power/Kconfig +1 -1

 config FREEZER
-	def_bool PM_SLEEP
+	def_bool PM_SLEEP || CGROUP_FREEZER
 

we did it that way. Spose that makes sense.

Quoted 46 lines

kernel/power/Kconfig +4 -0

+        help
+          Provides a way to freeze and unfreeze all tasks in a
+	  cgroup.
+
 config CGROUP_DEVICE
 	bool "Device controller for cgroups"
 	depends on CGROUPS && EXPERIMENTAL

Index: linux-2.6.27-rc1-mm1/kernel/Makefile
===================================================================

kernel/Makefile +1 -0

@@ -54,6 +54,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_COMPAT) += compat.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
 obj-$(CONFIG_CGROUP_DEBUG) += cgroup_debug.o
+obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CPUSETS) += cpuset.o
 obj-$(CONFIG_CGROUP_NS) += ns_cgroup.o
 obj-$(CONFIG_UTS_NS) += utsname.o

Index: linux-2.6.27-rc1-mm1/kernel/cgroup_freezer.c
===================================================================

kernel/cgroup_freezer.c new file +22 -0

@@ -0,0 +1,366 @@
+/*
+ * cgroup_freezer.c -  control group freezer subsystem
+ *
+ * Copyright IBM Corporation, 2007
+ *
+ * Author : Cedric Le Goater <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#include <linux/module.h>
+#include <linux/cgroup.h>
+#include <linux/fs.h>
+#include <linux/uaccess.h>
+#include <linux/freezer.h>
+#include <linux/seq_file.h>

kernel/cgroup_freezer.c line 25

Quoted 3 lines

kernel/cgroup_freezer.c new file +3 -0

+
+enum freezer_state {
+	STATE_RUNNING = 0,

That's a pretty vanilla-sounding identifier. Let's hope this file never ends up including drivers/net/sfc/net_driver.h by some means. That's rather unlikely, but someone could easily choose to implement a new STATE_RUNNING somewhere else.

Quoted 35 lines

kernel/cgroup_freezer.c new file +35 -0

+	STATE_FREEZING,
+	STATE_FROZEN,
+};
+
+struct freezer {
+	struct cgroup_subsys_state css;
+	enum freezer_state state;
+	spinlock_t lock; /* protects _writes_ to state */
+};
+
+static inline struct freezer *cgroup_freezer(
+		struct cgroup *cgroup)
+{
+	return container_of(
+		cgroup_subsys_state(cgroup, freezer_subsys_id),
+		struct freezer, css);
+}
+
+static inline struct freezer *task_freezer(struct task_struct *task)
+{
+	return container_of(task_subsys_state(task, freezer_subsys_id),
+			    struct freezer, css);
+}
+
+int cgroup_frozen(struct task_struct *task)
+{
+	struct freezer *freezer;
+	enum freezer_state state;
+
+	task_lock(task);
+	freezer = task_freezer(task);
+	state = freezer->state;
+	task_unlock(task);
+
+	return state == STATE_FROZEN;