From: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
To: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org,
Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v2 4/5] don't take cgroup_mutex in destroy()
Date: Tue, 24 Apr 2012 11:31:54 +0900 [thread overview]
Message-ID: <4F96109A.8000907@jp.fujitsu.com> (raw)
In-Reply-To: <1335209867-1831-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
(2012/04/24 4:37), Glauber Costa wrote:
> Most of the destroy functions are only doing very simple things
> like freeing memory.
>
> The ones who goes through lists and such, already use its own
> locking for those.
>
> * The cgroup itself won't go away until we free it, (after destroy)
> * The parent won't go away because we hold a reference count
> * There are no more tasks in the cgroup, and the cgroup is declared
> dead (cgroup_is_removed() == true)
>
> [v2: don't cgroup_lock the freezer and blkcg ]
>
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> CC: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> CC: Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> CC: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> kernel/cgroup.c | 9 ++++-----
> 1 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 932c318..976d332 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -869,13 +869,13 @@ static void cgroup_diput(struct dentry *dentry, struct inode *inode)
> * agent */
> synchronize_rcu();
>
> - mutex_lock(&cgroup_mutex);
> /*
> * Release the subsystem state objects.
> */
> for_each_subsys(cgrp->root, ss)
> ss->destroy(cgrp);
>
> + mutex_lock(&cgroup_mutex);
> cgrp->root->number_of_cgroups--;
> mutex_unlock(&cgroup_mutex);
>
> @@ -3994,13 +3994,12 @@ static long cgroup_create(struct cgroup *parent, struct dentry *dentry,
>
> err_destroy:
>
> + mutex_unlock(&cgroup_mutex);
> for_each_subsys(root, ss) {
> if (cgrp->subsys[ss->subsys_id])
> ss->destroy(cgrp);
> }
>
> - mutex_unlock(&cgroup_mutex);
> -
> /* Release the reference count that we took on the superblock */
> deactivate_super(sb);
>
> @@ -4349,9 +4348,9 @@ int __init_or_module cgroup_load_subsys(struct cgroup_subsys *ss)
> int ret = cgroup_init_idr(ss, css);
> if (ret) {
> dummytop->subsys[ss->subsys_id] = NULL;
> + mutex_unlock(&cgroup_mutex);
> ss->destroy(dummytop);
> subsys[i] = NULL;
> - mutex_unlock(&cgroup_mutex);
> return ret;
> }
> }
> @@ -4447,10 +4446,10 @@ void cgroup_unload_subsys(struct cgroup_subsys *ss)
> * pointer to find their state. note that this also takes care of
> * freeing the css_id.
> */
> + mutex_unlock(&cgroup_mutex);
> ss->destroy(dummytop);
> dummytop->subsys[ss->subsys_id] = NULL;
>
I'm not fully sure but...dummytop->subsys[] update can be done without locking ?
Thanks,
-Kame
next prev parent reply other threads:[~2012-04-24 2:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 19:37 [PATCH v2 0/5] Fix problem with static_key decrement Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-23 19:37 ` [PATCH v2 1/5] don't attach a task to a dead cgroup Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:20 ` KAMEZAWA Hiroyuki
2012-04-23 19:37 ` [PATCH v2 2/5] blkcg: protect blkcg->policy_list Glauber Costa
2012-04-23 19:37 ` Glauber Costa
2012-04-23 19:37 ` [PATCH v2 3/5] change number_of_cpusets to an atomic Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:25 ` KAMEZAWA Hiroyuki
2012-04-24 15:02 ` Christoph Lameter
[not found] ` <alpine.DEB.2.00.1204241001050.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2012-04-24 16:15 ` Glauber Costa
2012-04-24 16:15 ` Glauber Costa
[not found] ` <4F96D1A8.6040604-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 16:24 ` Christoph Lameter
[not found] ` <alpine.DEB.2.00.1204241120130.26005-sBS69tsa9Uj/9pzu0YdTqQ@public.gmane.org>
2012-04-24 16:30 ` Glauber Costa
2012-04-24 16:30 ` Glauber Costa
[not found] ` <4F96D50D.4020804-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 18:27 ` Christoph Lameter
2012-04-23 19:37 ` [PATCH v2 4/5] don't take cgroup_mutex in destroy() Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:31 ` KAMEZAWA Hiroyuki [this message]
[not found] ` <4F96109A.8000907-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-04-24 11:42 ` Glauber Costa
2012-04-24 11:42 ` Glauber Costa
[not found] ` <4F9691A8.1070106-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-25 8:01 ` Li Zefan
2012-04-23 19:37 ` [PATCH v2 5/5] decrement static keys on real destroy time Glauber Costa
2012-04-23 19:37 ` Glauber Costa
[not found] ` <1335209867-1831-6-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-04-24 2:40 ` KAMEZAWA Hiroyuki
[not found] ` <4F9612B9.7050705-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-04-24 11:41 ` Glauber Costa
2012-04-24 11:41 ` Glauber Costa
2012-04-25 0:22 ` KAMEZAWA Hiroyuki
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=4F96109A.8000907@jp.fujitsu.com \
--to=kamezawa.hiroyu-+cum20s59erqfuhtdcdx3a@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.