lkml.org 
[lkml]   [2008]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [BUGFIX]cgroup: fix potential deadlock in pre_destroy (v2)
KAMEZAWA Hiroyuki wrote:
> This is fixed one. Thank you for all help.
>
> Regards,
> -Kame
> ==
> As Balbir pointed out, memcg's pre_destroy handler has potential deadlock.
>
> It has following lock sequence.
>
> cgroup_mutex (cgroup_rmdir)
> -> pre_destroy -> mem_cgroup_pre_destroy-> force_empty
> -> cpu_hotplug.lock. (lru_add_drain_all->
> schedule_work->
> get_online_cpus)
>
> But, cpuset has following.
> cpu_hotplug.lock (call notifier)
> -> cgroup_mutex. (within notifier)
>
> Then, this lock sequence should be fixed.
>
> Considering how pre_destroy works, it's not necessary to holding
> cgroup_mutex() while calling it.
>
> As side effect, we don't have to wait at this mutex while memcg's force_empty
> works.(it can be long when there are tons of pages.)
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> ---
> kernel/cgroup.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> Index: mmotm-2.6.28-Nov10/kernel/cgroup.c
> ===================================================================
> --- mmotm-2.6.28-Nov10.orig/kernel/cgroup.c
> +++ mmotm-2.6.28-Nov10/kernel/cgroup.c
> @@ -2475,10 +2475,7 @@ static int cgroup_rmdir(struct inode *un
> mutex_unlock(&cgroup_mutex);
> return -EBUSY;
> }
> -
> - parent = cgrp->parent;
> - root = cgrp->root;
> - sb = root->sb;
> + mutex_unlock(&cgroup_mutex);
>
> /*
> * Call pre_destroy handlers of subsys. Notify subsystems
> @@ -2486,7 +2483,14 @@ static int cgroup_rmdir(struct inode *un
> */
> cgroup_call_pre_destroy(cgrp);
>
> - if (cgroup_has_css_refs(cgrp)) {
> + mutex_lock(&cgroup_mutex);
> + parent = cgrp->parent;
> + root = cgrp->root;
> + sb = root->sb;
> +
> + if (atomic_read(&cgrp->count)
> + || !list_empty(&cgrp->children)
> + || cgroup_has_css_refs(cgrp)) {
> mutex_unlock(&cgroup_mutex);
> return -EBUSY;
> }
>

I think the last statement deserves a comment that after re-acquiring the lock,
we need to check if count, children or references changed. Otherwise looks good,
though I've not yet tested it.

Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>

--
Balbir


\
 
 \ /
  Last update: 2008-11-12 12:29    [W:0.064 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site