Re: [PATCH 1/2] fix bad behavior in use_hierarchy file

[Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>]

On Tue, 26 Jun 2012 19:47:13 +0400
Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 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.