From: Tejun Heo <tj@kernel.org>
To: rjw@sisk.pl, oleg@redhat.com
Cc: linux-kernel@vger.kernel.org, lizefan@huawei.com,
containers@lists.linux-foundation.org, cgroups@vger.kernel.org,
Tejun Heo <tj@kernel.org>
Subject: [PATCH 5/7] cgroup_freezer: allow moving tasks in and out of a frozen cgroup
Date: Tue, 16 Oct 2012 15:28:44 -0700 [thread overview]
Message-ID: <1350426526-14254-6-git-send-email-tj@kernel.org> (raw)
In-Reply-To: <1350426526-14254-1-git-send-email-tj@kernel.org>
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.
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>
---
kernel/cgroup_freezer.c | 51 ++++++++++++++++++++++++++++------------------
1 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index 557f367..0b0e105 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -152,27 +152,38 @@ static void freezer_destroy(struct cgroup *cgroup)
/*
* The call to cgroup_lock() in the freezer.state write method prevents
- * a write to that file racing against an attach, and hence the
- * can_attach() result will remain valid until the attach completes.
+ * a write to that file racing against an attach, and hence we don't need
+ * to worry about racing against migration.
*/
-static int freezer_can_attach(struct cgroup *new_cgroup,
- struct cgroup_taskset *tset)
+static void freezer_attach(struct cgroup *new_cgrp, struct cgroup_taskset *tset)
{
- struct freezer *freezer;
+ struct freezer *freezer = cgroup_freezer(new_cgrp);
struct task_struct *task;
+ spin_lock_irq(&freezer->lock);
+
/*
- * Anything frozen can't move or be moved to/from.
+ * Make the new tasks conform to the current state of @new_cgrp.
+ * For simplicity, when migrating any task to a FROZEN cgroup, we
+ * revert it to FREEZING and let update_if_frozen() determine the
+ * correct state later.
+ *
+ * Tasks in @tset are on @new_cgrp but may not conform to its
+ * current state before executing the following - !frozen tasks may
+ * be visible in a FROZEN cgroup and frozen tasks in a THAWED one.
+ * This means that, to determine whether to freeze, one should test
+ * whether the state equals THAWED.
*/
- cgroup_taskset_for_each(task, new_cgroup, tset)
- if (cgroup_freezing(task))
- return -EBUSY;
-
- freezer = cgroup_freezer(new_cgroup);
- if (freezer->state != CGROUP_THAWED)
- return -EBUSY;
+ cgroup_taskset_for_each(task, new_cgrp, tset) {
+ if (freezer->state == CGROUP_THAWED) {
+ __thaw_task(task);
+ } else {
+ freeze_task(task);
+ freezer->state = CGROUP_FREEZING;
+ }
+ }
- return 0;
+ spin_unlock_irq(&freezer->lock);
}
static void freezer_fork(struct task_struct *task)
@@ -190,12 +201,12 @@ static void freezer_fork(struct task_struct *task)
goto out;
spin_lock_irq(&freezer->lock);
- BUG_ON(freezer->state == CGROUP_FROZEN);
-
- /* Locking avoids race with FREEZING -> THAWED transitions. */
- if (freezer->state == CGROUP_FREEZING)
+ /*
+ * @task might have been just migrated into a FROZEN cgroup. Test
+ * equality with THAWED. Read the comment in freezer_attach().
+ */
+ if (freezer->state != CGROUP_THAWED)
freeze_task(task);
-
spin_unlock_irq(&freezer->lock);
out:
rcu_read_unlock();
@@ -352,7 +363,7 @@ struct cgroup_subsys freezer_subsys = {
.create = freezer_create,
.destroy = freezer_destroy,
.subsys_id = freezer_subsys_id,
- .can_attach = freezer_can_attach,
+ .attach = freezer_attach,
.fork = freezer_fork,
.base_cftypes = files,
--
1.7.7.3
next prev parent reply other threads:[~2012-10-16 22:29 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 22:28 [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking Tejun Heo
2012-10-16 22:28 ` [PATCH 1/7] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set Tejun Heo
2012-10-17 8:28 ` Li Zefan
2012-10-18 1:25 ` Li Zefan
2012-10-21 19:11 ` Oleg Nesterov
2012-10-21 19:22 ` Tejun Heo
2012-10-22 18:04 ` Oleg Nesterov
2012-10-22 21:16 ` Tejun Heo
2012-10-23 15:51 ` Oleg Nesterov
2012-10-24 19:04 ` Tejun Heo
2012-10-25 17:42 ` Oleg Nesterov
2012-12-20 5:25 ` Herton Ronaldo Krzesinski
2012-12-28 21:22 ` [PATCH] cgroup: remove unused dummy cgroup_fork_callbacks() Tejun Heo
2012-10-16 22:28 ` [PATCH 2/7] freezer: add missing mb's to freezer_count() and freezer_should_skip() Tejun Heo
2012-10-22 17:44 ` Oleg Nesterov
2012-10-22 21:13 ` Tejun Heo
2012-10-23 15:39 ` Oleg Nesterov
2012-10-24 18:57 ` Tejun Heo
2012-10-25 16:39 ` [PATCH 0/1] (Was: freezer: add missing mb's to freezer_count() and freezer_should_skip()) Oleg Nesterov
2012-10-25 16:39 ` [PATCH 1/1] freezer: change ptrace_stop/do_signal_stop to use freezable_schedule() Oleg Nesterov
2012-10-25 17:18 ` Tejun Heo
2012-10-25 17:34 ` Oleg Nesterov
2012-10-25 17:36 ` Tejun Heo
2012-10-26 17:45 ` [PATCH v2 0/1] " Oleg Nesterov
2012-10-26 17:46 ` [PATCH v2 1/1] " Oleg Nesterov
2012-10-26 17:52 ` Tejun Heo
2012-10-26 18:01 ` Oleg Nesterov
2012-10-26 21:14 ` Rafael J. Wysocki
2012-10-26 21:29 ` Rafael J. Wysocki
2012-10-26 21:29 ` Tejun Heo
2012-10-28 0:16 ` Rafael J. Wysocki
2012-10-27 22:22 ` Ben Hutchings
2012-10-28 13:45 ` Oleg Nesterov
2012-10-16 22:28 ` [PATCH 3/7] cgroup_freezer: make it official that writes to freezer.state don't fail Tejun Heo
2012-10-16 22:28 ` [PATCH 4/7] cgroup_freezer: don't stall transition to FROZEN for PF_NOFREEZE or PF_FREEZER_SKIP tasks Tejun Heo
2012-10-22 18:34 ` Oleg Nesterov
2012-10-22 21:18 ` Tejun Heo
2012-10-23 15:55 ` Oleg Nesterov
2012-10-24 19:06 ` Tejun Heo
2012-10-25 17:12 ` [PATCH 0/1] (Was: cgroup_freezer: don't stall transition to FROZEN for PF_NOFREEZE or PF_FREEZER_SKIP tasks) Oleg Nesterov
2012-10-25 17:12 ` [PATCH 1/1] freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD Oleg Nesterov
2012-10-25 17:20 ` Tejun Heo
2012-10-25 17:37 ` Oleg Nesterov
2012-10-25 17:37 ` Tejun Heo
2012-10-25 20:13 ` Rafael J. Wysocki
2012-10-16 22:28 ` Tejun Heo [this message]
2012-10-22 19:25 ` [PATCH 5/7] cgroup_freezer: allow moving tasks in and out of a frozen cgroup Oleg Nesterov
2012-10-22 21:25 ` Tejun Heo
2012-10-23 16:14 ` Oleg Nesterov
2012-10-16 22:28 ` [PATCH 6/7] cgroup_freezer: prepare update_if_frozen() for locking change Tejun Heo
2012-10-16 22:28 ` [PATCH 7/7] cgroup_freezer: don't use cgroup_lock_live_group() Tejun Heo
2012-10-17 19:16 ` [PATCHSET cgroup/for-3.8] cgroup_freezer: allow migration regardless of freezer state and update locking Matt Helsley
2012-10-18 21:14 ` Tejun Heo
2012-10-18 22:21 ` Matt Helsley
2012-10-18 22:35 ` Tejun Heo
2012-10-18 23:47 ` Matt Helsley
2012-10-19 0:01 ` Tejun Heo
2012-10-19 1:29 ` Matt Helsley
2012-10-19 20:02 ` Tejun Heo
2012-10-19 16:54 ` Rafael J. Wysocki
2012-10-19 20:04 ` Tejun Heo
2012-10-21 19:18 ` Oleg Nesterov
2012-10-21 19:24 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1350426526-14254-6-git-send-email-tj@kernel.org \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=oleg@redhat.com \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome