From: menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
To: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Cc: Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Peter Zijlstra
<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
Subject: [PATCH 08/29] task containersv11 shared container subsystem group arrays avoid lockdep warning
Date: Tue, 11 Sep 2007 12:52:47 -0700 [thread overview]
Message-ID: <20070911200145.928708000@menage.corp.google.com> (raw)
In-Reply-To: 20070911195239.997111000@menage.corp.google.com
[-- Attachment #1: task-containersv11-shared-container-subsystem-group-arrays-avoid-lockdep-warning.patch --]
[-- Type: text/plain, Size: 3113 bytes --]
From: Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
I think this is the right way to handle the lockdep false-positive in the
current cgroups patches, but I'm not that familiar with lockdep so any
suggestions for a better approach are welcomed.
In order to avoid a false-positive lockdep warning, we lock the root inode
of a new filesystem mount prior to taking cgroup_mutex, to preserve the
invariant that cgroup_mutex nests inside inode->i_mutex. In order to
prevent a lockdep false positive when locking i_mutex on a newly-created
cgroup directory inode we use mutex_lock_nested(), with a nesting level
of I_MUTEX_CHILD since the new inode will ultimately be a child directory
of the parent whose i_mutex is nested outside of cgroup_mutex.
Signed-off-by: Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Acked-by: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
---
kernel/cgroup.c | 17 +++++++----------
1 files changed, 7 insertions(+), 10 deletions(-)
diff -puN kernel/cgroup.c~task-cgroupsv11-shared-cgroup-subsystem-group-arrays-avoid-lockdep-warning kernel/cgroup.c
--- a/kernel/cgroup.c~task-cgroupsv11-shared-cgroup-subsystem-group-arrays-avoid-lockdep-warning
+++ a/kernel/cgroup.c
@@ -867,13 +867,16 @@ static int cgroup_get_sb(struct file_
} else {
/* New superblock */
struct cgroup *cont = &root->top_cgroup;
+ struct inode *inode;
BUG_ON(sb->s_root != NULL);
ret = cgroup_get_rootdir(sb);
if (ret)
goto drop_new_super;
+ inode = sb->s_root->d_inode;
+ mutex_lock(&inode->i_mutex);
mutex_lock(&cgroup_mutex);
/*
@@ -886,12 +889,14 @@ static int cgroup_get_sb(struct file_
ret = allocate_cg_links(css_set_count, &tmp_cg_links);
if (ret) {
mutex_unlock(&cgroup_mutex);
+ mutex_unlock(&inode->i_mutex);
goto drop_new_super;
}
ret = rebind_subsystems(root, root->subsys_bits);
if (ret == -EBUSY) {
mutex_unlock(&cgroup_mutex);
+ mutex_unlock(&inode->i_mutex);
goto drop_new_super;
}
@@ -931,16 +936,8 @@ static int cgroup_get_sb(struct file_
BUG_ON(!list_empty(&cont->children));
BUG_ON(root->number_of_cgroups != 1);
- /*
- * I believe that it's safe to nest i_mutex inside
- * cgroup_mutex in this case, since no-one else can
- * be accessing this directory yet. But we still need
- * to teach lockdep that this is the case - currently
- * a cgroupfs remount triggers a lockdep warning
- */
- mutex_lock(&cont->dentry->d_inode->i_mutex);
cgroup_populate_dir(cont);
- mutex_unlock(&cont->dentry->d_inode->i_mutex);
+ mutex_unlock(&inode->i_mutex);
mutex_unlock(&cgroup_mutex);
}
@@ -1358,7 +1355,7 @@ static int cgroup_create_file(struct
/* start with the directory inode held, so that we can
* populate it without racing with another mkdir */
- mutex_lock(&inode->i_mutex);
+ mutex_lock_nested(&inode->i_mutex, I_MUTEX_CHILD);
} else if (S_ISREG(mode)) {
inode->i_size = 0;
inode->i_fop = &cgroup_file_operations;
_
--
next prev parent reply other threads:[~2007-09-11 19:52 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 19:52 [PATCH 00/29] Rename Containers to Control Groups menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 01/29] task containersv11 basic task container framework menage-hpIqsD4AKlfQT0dZR+AlfA
[not found] ` <20070911200144.779221000-B63HFAS8fGlSzHKm+aFRNNkmqwFzkYv6@public.gmane.org>
2007-09-11 20:07 ` Andrew Morton
[not found] ` <20070911130731.e9df6e65.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2007-09-11 20:11 ` Paul Menage
2007-09-30 4:40 ` Paul Jackson
[not found] ` <20070929214043.57e9cc39.pj-sJ/iWh9BUns@public.gmane.org>
2007-09-30 5:10 ` Paul Jackson
[not found] ` <20070929221030.04881227.pj-sJ/iWh9BUns@public.gmane.org>
2007-09-30 5:14 ` Paul Jackson
2007-09-30 7:10 ` Paul Menage
[not found] ` <6599ad830709300010xda1e97cp8c569ce08a87a86b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-09-30 9:03 ` Andrew Morton
[not found] ` <20070930020330.6bd34dd4.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2007-09-30 9:15 ` Paul Jackson
[not found] ` <20070930021536.3bd65dc3.pj-sJ/iWh9BUns@public.gmane.org>
2007-09-30 9:29 ` Andrew Morton
[not found] ` <20070930022942.b36dd34f.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2007-09-30 9:36 ` Paul Jackson
2007-09-11 19:52 ` [PATCH 02/29] task containersv11 basic task container framework fix menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 03/29] task containersv11 add tasks file interface menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 04/29] task containersv11 add fork exit hooks menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 05/29] task containersv11 add container_clone interface menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 06/29] task containersv11 add procfs interface menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 07/29] task containersv11 shared container subsystem group arrays menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` menage-hpIqsD4AKlfQT0dZR+AlfA [this message]
2007-09-11 19:52 ` [PATCH 09/29] task containersv11 shared container subsystem group arrays include fix menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 10/29] task containersv11 automatic userspace notification of idle containers menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 11/29] task containersv11 make cpusets a client of containers menage-hpIqsD4AKlfQT0dZR+AlfA
[not found] ` <20070911200146.422879000-B63HFAS8fGlSzHKm+aFRNNkmqwFzkYv6@public.gmane.org>
2007-09-30 6:25 ` Paul Jackson
[not found] ` <20070929232513.63fe2d9c.pj-sJ/iWh9BUns@public.gmane.org>
2007-09-30 7:11 ` Paul Menage
[not found] ` <6599ad830709300011q6831a17ei60f21a06f795bead-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-09-30 7:19 ` Paul Jackson
2007-09-11 19:52 ` [PATCH 12/29] task containersv11 example cpu accounting subsystem menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 13/29] task containersv11 simple task container debug info subsystem menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 14/29] add containerstats v3 menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 15/29] add containerstats v3 fix menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 16/29] containers implement namespace tracking subsystem menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 17/29] containers implement namespace tracking subsystem fix order of container subsystems in init kconfig menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 18/29] memory controller add documentation menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 19/29] memory controller resource counters v7 menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:52 ` [PATCH 20/29] memory controller resource counters v7 fix menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 21/29] memory controller containers setup v7 menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 22/29] memory controller accounting " menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 23/29] memory controller memory accounting v7 menage-hpIqsD4AKlfQT0dZR+AlfA
[not found] ` <20070911200148.396756000-B63HFAS8fGlSzHKm+aFRNNkmqwFzkYv6@public.gmane.org>
2007-09-12 20:56 ` Peter Zijlstra
2007-09-13 9:49 ` Balbir Singh
[not found] ` <46E9078D.5040908-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2007-09-13 10:18 ` Peter Zijlstra
2007-09-13 10:29 ` Balbir Singh
2007-09-11 19:53 ` [PATCH 24/29] memory controller task migration v7 menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 25/29] memory controller add per container lru and reclaim v7 menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 26/29] memory controller add per container lru and reclaim v7 fix menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 27/29] memory controller oom handling v7 menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 28/29] memory controller add switch to control what type of pages to limit v7 menage-hpIqsD4AKlfQT0dZR+AlfA
2007-09-11 19:53 ` [PATCH 29/29] memory controller make page_referenced container aware v7 menage-hpIqsD4AKlfQT0dZR+AlfA
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=20070911200145.928708000@menage.corp.google.com \
--to=menage-hpiqsd4aklfqt0dzr+alfa@public.gmane.org \
--cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
/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