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 7/7] cgroup_freezer: don't use cgroup_lock_live_group()
Date: Tue, 16 Oct 2012 15:28:46 -0700 [thread overview]
Message-ID: <1350426526-14254-8-git-send-email-tj@kernel.org> (raw)
In-Reply-To: <1350426526-14254-1-git-send-email-tj@kernel.org>
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>
---
kernel/cgroup_freezer.c | 66 +++++++---------------------------------------
1 files changed, 10 insertions(+), 56 deletions(-)
diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index 3d45503..8a92b0e 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -84,50 +84,6 @@ static const char *freezer_state_strs[] = {
struct cgroup_subsys freezer_subsys;
-/* Locks taken and their ordering
- * ------------------------------
- * cgroup_mutex (AKA cgroup_lock)
- * freezer->lock
- * css_set_lock
- * task->alloc_lock (AKA task_lock)
- * task->sighand->siglock
- *
- * cgroup code forces css_set_lock to be taken before task->alloc_lock
- *
- * freezer_create(), freezer_destroy():
- * cgroup_mutex [ by cgroup core ]
- *
- * freezer_can_attach():
- * cgroup_mutex (held by caller of can_attach)
- *
- * freezer_fork() (preserving fork() performance means can't take cgroup_mutex):
- * freezer->lock
- * sighand->siglock (if the cgroup is freezing)
- *
- * freezer_read():
- * cgroup_mutex
- * freezer->lock
- * write_lock css_set_lock (cgroup iterator start)
- * task->alloc_lock
- * read_lock css_set_lock (cgroup iterator start)
- *
- * freezer_write() (freeze):
- * cgroup_mutex
- * freezer->lock
- * write_lock css_set_lock (cgroup iterator start)
- * task->alloc_lock
- * read_lock css_set_lock (cgroup iterator start)
- * sighand->siglock (fake signal delivery inside freeze_task())
- *
- * freezer_write() (unfreeze):
- * cgroup_mutex
- * freezer->lock
- * write_lock css_set_lock (cgroup iterator start)
- * task->alloc_lock
- * read_lock css_set_lock (cgroup iterator start)
- * task->alloc_lock (inside __thaw_task(), prevents race with refrigerator())
- * sighand->siglock
- */
static struct cgroup_subsys_state *freezer_create(struct cgroup *cgroup)
{
struct freezer *freezer;
@@ -151,9 +107,13 @@ 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 we don't need
- * to worry about racing against migration.
+ * Tasks can be migrated into a different freezer anytime regardless of its
+ * current state. freezer_attach() is responsible for making new tasks
+ * conform to the current state.
+ *
+ * Freezer state changes and task migration are synchronized via
+ * @freezer->lock. freezer_attach() makes the new tasks conform to the
+ * current state and all following state changes can see the new tasks.
*/
static void freezer_attach(struct cgroup *new_cgrp, struct cgroup_taskset *tset)
{
@@ -217,8 +177,8 @@ out:
* partially frozen when we exitted write. Caller must hold freezer->lock.
*
* Task states and freezer state might disagree while tasks are being
- * migrated into @cgroup, so we can't verify task states against @freezer
- * state here. See freezer_attach() for details.
+ * migrated into or out of @cgroup, so we can't verify task states against
+ * @freezer state here. See freezer_attach() for details.
*/
static void update_if_frozen(struct cgroup *cgroup, struct freezer *freezer)
{
@@ -255,15 +215,11 @@ static int freezer_read(struct cgroup *cgroup, struct cftype *cft,
struct freezer *freezer;
enum freezer_state state;
- if (!cgroup_lock_live_group(cgroup))
- return -ENODEV;
-
freezer = cgroup_freezer(cgroup);
spin_lock_irq(&freezer->lock);
update_if_frozen(cgroup, freezer);
state = freezer->state;
spin_unlock_irq(&freezer->lock);
- cgroup_unlock();
seq_puts(m, freezer_state_strs[state]);
seq_putc(m, '\n');
@@ -297,6 +253,7 @@ static void freezer_change_state(struct cgroup *cgroup,
{
struct freezer *freezer = cgroup_freezer(cgroup);
+ /* also synchronizes against task migration, see freezer_attach() */
spin_lock_irq(&freezer->lock);
switch (goal_state) {
@@ -332,10 +289,7 @@ static int freezer_write(struct cgroup *cgroup,
else
return -EINVAL;
- if (!cgroup_lock_live_group(cgroup))
- return -ENODEV;
freezer_change_state(cgroup, goal_state);
- cgroup_unlock();
return 0;
}
--
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 ` [PATCH 5/7] cgroup_freezer: allow moving tasks in and out of a frozen cgroup Tejun Heo
2012-10-22 19:25 ` 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 ` Tejun Heo [this message]
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-8-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