From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kamezawa Hiroyuki Subject: Re: [PATCH] fix bad behavior in use_hierarchy file Date: Mon, 25 Jun 2012 18:54:49 +0900 Message-ID: <4FE83569.9080301@jp.fujitsu.com> References: <1340616061-1955-1-git-send-email-glommer@parallels.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1340616061-1955-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Glauber Costa Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Andrew Morton , devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, Dhaval Giani , Michal Hocko , Johannes Weiner (2012/06/25 18:21), Glauber Costa wrote: > I have an application that does the following: > > * copy the state of all controllers attached to a hierarchy > * replicate it as a child of the current level. > > I would expect writes to the files to mostly succeed, since they > are inheriting sane values from parents. > > But that is not the case for use_hierarchy. If it is set to 0, we > succeed ok. If we're set to 1, the value of the file is automatically > set to 1 in the children, but if userspace tries to write the > very same 1, it will fail. That same situation happens if we > set use_hierarchy, create a child, and then try to write 1 again. > > Now, there is no reason whatsoever for failing to write a value > that is already there. It doesn't even match the comments, that > states: > > /* If parent's use_hierarchy is set, we can't make any modifications > * in the child subtrees... > > since we are not changing anything. > > The following patch tests the new value against the one we're storing, > and automatically return 0 if we're not proposing a change. > > Signed-off-by: Glauber Costa > CC: Dhaval Giani > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner Hm. Acked-by: KAMEZAWA Hiroyuki From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx106.postini.com [74.125.245.106]) by kanga.kvack.org (Postfix) with SMTP id E5DBC6B0329 for ; Mon, 25 Jun 2012 05:56:54 -0400 (EDT) Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 0B9D13EE0BD for ; Mon, 25 Jun 2012 18:56:53 +0900 (JST) Received: from smail (m3 [127.0.0.1]) by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id E661945DEB2 for ; Mon, 25 Jun 2012 18:56:52 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93]) by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id CD3A745DE9E for ; Mon, 25 Jun 2012 18:56:52 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id BA0A01DB8044 for ; Mon, 25 Jun 2012 18:56:52 +0900 (JST) Received: from m1000.s.css.fujitsu.com (m1000.s.css.fujitsu.com [10.240.81.136]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 726B71DB803E for ; Mon, 25 Jun 2012 18:56:52 +0900 (JST) Message-ID: <4FE83569.9080301@jp.fujitsu.com> Date: Mon, 25 Jun 2012 18:54:49 +0900 From: Kamezawa Hiroyuki MIME-Version: 1.0 Subject: Re: [PATCH] fix bad behavior in use_hierarchy file References: <1340616061-1955-1-git-send-email-glommer@parallels.com> In-Reply-To: <1340616061-1955-1-git-send-email-glommer@parallels.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Glauber Costa Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , devel@openvz.org, Dhaval Giani , Michal Hocko , Johannes Weiner (2012/06/25 18:21), Glauber Costa wrote: > I have an application that does the following: > > * copy the state of all controllers attached to a hierarchy > * replicate it as a child of the current level. > > I would expect writes to the files to mostly succeed, since they > are inheriting sane values from parents. > > But that is not the case for use_hierarchy. If it is set to 0, we > succeed ok. If we're set to 1, the value of the file is automatically > set to 1 in the children, but if userspace tries to write the > very same 1, it will fail. That same situation happens if we > set use_hierarchy, create a child, and then try to write 1 again. > > Now, there is no reason whatsoever for failing to write a value > that is already there. It doesn't even match the comments, that > states: > > /* If parent's use_hierarchy is set, we can't make any modifications > * in the child subtrees... > > since we are not changing anything. > > The following patch tests the new value against the one we're storing, > and automatically return 0 if we're not proposing a change. > > Signed-off-by: Glauber Costa > CC: Dhaval Giani > CC: Michal Hocko > CC: Kamezawa Hiroyuki > CC: Johannes Weiner Hm. Acked-by: KAMEZAWA Hiroyuki -- 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