On Tue, 26 Jun 2012 19:47:13 +0400 Glauber Costa <glommer@xxxxxxxxxxxxx> wrote: > --- 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>