Re: [PATCH 1/3] cgroup: don't destroy the default root

[Li Zefan]

On 2014/6/3 20:57, Tejun Heo wrote:
> Hello, Li.
> 
> On Tue, Jun 03, 2014 at 12:04:38PM +0800, Li Zefan wrote:
>>  static void cgroup_get(struct cgroup *cgrp)
>>  {
>>  	WARN_ON_ONCE(cgroup_is_dead(cgrp));
>> -	css_get(&cgrp->self);
>> +	if (!(cgrp->self.flags & CSS_NO_REF))
>> +		css_get(&cgrp->self);
> 
> Hmmm?  The same condition is tested by css_get().  Why should it be
> tested again here?
> 

Oh, I completely ignored that.

>>  static void cgroup_put(struct cgroup *cgrp)
>>  {
>> -	css_put(&cgrp->self);
>> +	if (!(cgrp->self.flags & CSS_NO_REF))
>> +		css_put(&cgrp->self);
> 
> Ditto.
> 
>> @@ -1781,10 +1783,12 @@ static void cgroup_kill_sb(struct super_block *sb)
>>  	 * This prevents new mounts by disabling percpu_ref_tryget_live().
>>  	 * cgroup_mount() may wait for @root's release.
>>  	 */
>> -	if (css_has_online_children(&root->cgrp.self))
>> +	if (css_has_online_children(&root->cgrp.self)) {
>>  		cgroup_put(&root->cgrp);
>> -	else
>> -		percpu_ref_kill(&root->cgrp.self.refcnt);
>> +	} else {
>> +		if (root != &cgrp_dfl_root)
>> +			percpu_ref_kill(&root->cgrp.self.refcnt);
>> +	}
> 
> As conceptually percpu_ref_kill() just puts the base ref and the
> dfl_root's refcnt never reaches zero, it won't actually trigger.

Yes it will, just try mount && umount.

I think it's because cgroup_get() is a no-op for CSS_NO_REF, so it has
only the base ref, so percpu_ref_iill() will actually schedule the
call to css_release().

> Hmmm.... wouldn't the above leak a ref each time the default hierarchy
> is unmounted tho?  Shouldn't it be like the following?
> 

cgroup_get() is a no-op for root cgroup of the default root, so there's
no leak, but still better to call cgroup_put().

I'll send an updated patch.

> 	if (root == &cgrp_dfl_root || css_has_online_children(...))
> 		cgroup_put(&root->cgrp);
> 	else
> 		percpu_ref_kill(...);
> 
> Thanks.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/