From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx127.postini.com [74.125.245.127]) by kanga.kvack.org (Postfix) with SMTP id 3CE0F6B0089 for ; Thu, 19 Jul 2012 08:38:23 -0400 (EDT) Date: Thu, 19 Jul 2012 14:38:20 +0200 From: Michal Hocko Subject: Re: + hugetlb-cgroup-simplify-pre_destroy-callback.patch added to -mm tree Message-ID: <20120719123820.GG2864@tiehlicka.suse.cz> References: <20120718212637.133475C0050@hpza9.eem.corp.google.com> <20120719113915.GC2864@tiehlicka.suse.cz> <87r4s8gcwe.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r4s8gcwe.fsf@skywalker.in.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: "Aneesh Kumar K.V" Cc: akpm@linux-foundation.org, mm-commits@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, liwanp@linux.vnet.ibm.com, Tejun Heo , Li Zefan , cgroups mailinglist , linux-mm@kvack.org On Thu 19-07-12 17:51:05, Aneesh Kumar K.V wrote: > Michal Hocko writes: > > > From 621ed1c9dab63bd82205bd5266eb9974f86a0a3f Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Thu, 19 Jul 2012 13:23:23 +0200 > > Subject: [PATCH] cgroup: keep cgroup_mutex locked for pre_destroy > > > > 3fa59dfb (cgroup: fix potential deadlock in pre_destroy) dropped the > > cgroup_mutex lock while calling pre_destroy callbacks because memory > > controller could deadlock because force_empty triggered reclaim. > > Since "memcg: move charges to root cgroup if use_hierarchy=0" there is > > no reclaim going on from mem_cgroup_force_empty though so we can safely > > keep the cgroup_mutex locked. This has an advantage that no tasks might > > be added during pre_destroy callback and so the handlers don't have to > > consider races when new tasks add new charges. This simplifies the > > implementation. > > --- > > kernel/cgroup.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > > index 0f3527d..9dba05d 100644 > > --- a/kernel/cgroup.c > > +++ b/kernel/cgroup.c > > @@ -4181,7 +4181,6 @@ again: > > mutex_unlock(&cgroup_mutex); > > return -EBUSY; > > } > > - mutex_unlock(&cgroup_mutex); > > > > /* > > * In general, subsystem has no css->refcnt after pre_destroy(). But > > @@ -4204,7 +4203,6 @@ again: > > return ret; > > } > > > > - mutex_lock(&cgroup_mutex); > > parent = cgrp->parent; > > if (atomic_read(&cgrp->count) || !list_empty(&cgrp->children)) { > > clear_bit(CGRP_WAIT_ON_RMDIR, &cgrp->flags); > > mem_cgroup_force_empty still calls > > lru_add_drain_all > ->schedule_on_each_cpu > -> get_online_cpus > ->mutex_lock(&cpu_hotplug.lock); > > So wont we deadlock ? Yes you are right. I got it wrong. I thought that the reclaim is the main problem. It won't be that easy then and the origin mm patch (hugetlb-cgroup-simplify-pre_destroy-callback.patch) still needs a fix or to be dropped. > > -aneesh -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org