Re: [PATCH 1/2] fix bad behavior in use_hierarchy file
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2012-06-26 22:25:23
Also in:
cgroups
On Tue, 26 Jun 2012 19:47:13 +0400 Glauber Costa [off-list ref] wrote:
quoted hunk ↗ jump to hunk
--- a/mm/memcontrol.c +++ b/mm/memcontrol.c@@ -3989,6 +3989,10 @@ static int mem_cgroup_hierarchy_write(struct cgroup *cont, struct cftype *cft, parent_memcg = mem_cgroup_from_cont(parent); cgroup_lock(); + + if (memcg->use_hierarchy == val) + goto out; + /* * If parent's use_hierarchy is set, we can't make any modifications * in the child subtrees. If it is unset, then the change can@@ -4005,6 +4009,8 @@ static int mem_cgroup_hierarchy_write(struct cgroup *cont, struct cftype *cft, retval = -EBUSY; } else retval = -EINVAL; + +out: cgroup_unlock(); return retval;
hm. The various .write_u64() implementations go and return zero on success and cgroup_write_X64() sees this and rewrites the return value to `nbytes'. That was a bit naughty of us - it prevents a .write_u64() instance from being able to fully implement a partial write. We can *partially* implement a partial write, by returning a value between 1 and nbytes-1, but we can't return zero. It's a weird interface, it's a surprising interface and it was quite unnecessary to do it this way. Someone please slap Paul. It's hardly a big problem I, but that's why the unix write() interface was designed the way it is. -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>