From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761363Ab2D0UcH (ORCPT ); Fri, 27 Apr 2012 16:32:07 -0400 Received: from mail-pz0-f51.google.com ([209.85.210.51]:60563 "EHLO mail-pz0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760645Ab2D0UcE (ORCPT ); Fri, 27 Apr 2012 16:32:04 -0400 Date: Fri, 27 Apr 2012 13:31:59 -0700 From: Tejun Heo To: KAMEZAWA Hiroyuki Cc: Linux Kernel , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , Michal Hocko , Johannes Weiner , Frederic Weisbecker , Glauber Costa , Han Ying , "Aneesh Kumar K.V" , Andrew Morton , kamezawa.hiroyuki@gmail.com Subject: Re: [RFC][PATCH 7/9 v2] cgroup: avoid attaching task to a cgroup under rmdir() Message-ID: <20120427203159.GL26595@google.com> References: <4F9A327A.6050409@jp.fujitsu.com> <4F9A366E.9020307@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9A366E.9020307@jp.fujitsu.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 27, 2012 at 03:02:22PM +0900, KAMEZAWA Hiroyuki wrote: > attach_task() is done under cgroup_mutex() but ->pre_destroy() callback > in rmdir() isn't called under cgroup_mutex(). > > It's better to avoid attaching a task to a cgroup which > is under pre_destroy(). Considering memcg, the attached task may > increase resource usage after memcg's pre_destroy() confirms that > memcg is empty. This is not good. > > Signed-off-by: KAMEZAWA Hiroyuki Hmm... once memcg's pre_destroy() can't fail, I think what we should do is marking a cgroup DEAD before calling pre_destroy() and the existing cgroup_is_removed() check should be enough. Patches upto this point already make ->pre_destroy() not fail, right? Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx136.postini.com [74.125.245.136]) by kanga.kvack.org (Postfix) with SMTP id 05A7A6B0105 for ; Fri, 27 Apr 2012 16:32:04 -0400 (EDT) Received: by dadq36 with SMTP id q36so1549469dad.8 for ; Fri, 27 Apr 2012 13:32:04 -0700 (PDT) Date: Fri, 27 Apr 2012 13:31:59 -0700 From: Tejun Heo Subject: Re: [RFC][PATCH 7/9 v2] cgroup: avoid attaching task to a cgroup under rmdir() Message-ID: <20120427203159.GL26595@google.com> References: <4F9A327A.6050409@jp.fujitsu.com> <4F9A366E.9020307@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9A366E.9020307@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org List-ID: To: KAMEZAWA Hiroyuki Cc: Linux Kernel , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , Michal Hocko , Johannes Weiner , Frederic Weisbecker , Glauber Costa , Han Ying , "Aneesh Kumar K.V" , Andrew Morton , kamezawa.hiroyuki@gmail.com On Fri, Apr 27, 2012 at 03:02:22PM +0900, KAMEZAWA Hiroyuki wrote: > attach_task() is done under cgroup_mutex() but ->pre_destroy() callback > in rmdir() isn't called under cgroup_mutex(). > > It's better to avoid attaching a task to a cgroup which > is under pre_destroy(). Considering memcg, the attached task may > increase resource usage after memcg's pre_destroy() confirms that > memcg is empty. This is not good. > > Signed-off-by: KAMEZAWA Hiroyuki Hmm... once memcg's pre_destroy() can't fail, I think what we should do is marking a cgroup DEAD before calling pre_destroy() and the existing cgroup_is_removed() check should be enough. Patches upto this point already make ->pre_destroy() not fail, right? Thanks. -- tejun -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFC][PATCH 7/9 v2] cgroup: avoid attaching task to a cgroup under rmdir() Date: Fri, 27 Apr 2012 13:31:59 -0700 Message-ID: <20120427203159.GL26595@google.com> References: <4F9A327A.6050409@jp.fujitsu.com> <4F9A366E.9020307@jp.fujitsu.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Ft3LPhHttlF5CH2jvqk+CRMeZEtIUEZZR0XgVmJr8l0=; b=CykKi+dIxZXqeYM3ysQiWBhG7Cq9jjj+BQq53pxPP8pQ3mRKEV7fgJybSwIf6dvM0O EOPHnwO46ZUKXVHpf9K/3xZt8qyKdYpyQDzhR1Mea/KWjT9L6x5YpBRZ9x1wWViMe9b8 4ciQSoRc+fmJL4C9k7zJB2wzwGy/FFf6vM4yj8ixjKX7c7jki5bZsfifSie6Ma/YW3L/ et2D68+/7hxWwBD8Ly+k7y/JFS/qhJPy3IYQtjXq+8cgcqAdSPWU3oNZYT9ykqcNiRgW W+SB7nAc05dN+9cQQIHvjZt5yzZN2sfy6Br1q16ERNN+yQGGJRiImT1Pbl/ziIEqXJ1B MySw== Content-Disposition: inline In-Reply-To: <4F9A366E.9020307-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: KAMEZAWA Hiroyuki Cc: Linux Kernel , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Michal Hocko , Johannes Weiner , Frederic Weisbecker , Glauber Costa , Han Ying , "Aneesh Kumar K.V" , Andrew Morton , kamezawa.hiroyuki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org On Fri, Apr 27, 2012 at 03:02:22PM +0900, KAMEZAWA Hiroyuki wrote: > attach_task() is done under cgroup_mutex() but ->pre_destroy() callback > in rmdir() isn't called under cgroup_mutex(). > > It's better to avoid attaching a task to a cgroup which > is under pre_destroy(). Considering memcg, the attached task may > increase resource usage after memcg's pre_destroy() confirms that > memcg is empty. This is not good. > > Signed-off-by: KAMEZAWA Hiroyuki Hmm... once memcg's pre_destroy() can't fail, I think what we should do is marking a cgroup DEAD before calling pre_destroy() and the existing cgroup_is_removed() check should be enough. Patches upto this point already make ->pre_destroy() not fail, right? Thanks. -- tejun