lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fwa0ol86.fsf@skywalker.in.ibm.com>
Date:	Tue, 12 Jun 2012 16:22:57 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	linux-mm@...ck.org, dhillf@...il.com, rientjes@...gle.com,
	mhocko@...e.cz, akpm@...ux-foundation.org, hannes@...xchg.org,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [PATCH -V8 12/16] hugetlb/cgroup: Add support for cgroup removal

Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com> writes:

> (2012/06/09 17:59), Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"<aneesh.kumar@...ux.vnet.ibm.com>
>> 
>> This patch add support for cgroup removal. If we don't have parent
>> cgroup, the charges are moved to root cgroup.
>> 
>> Signed-off-by: Aneesh Kumar K.V<aneesh.kumar@...ux.vnet.ibm.com>
>
> I'm sorry if already pointed out....
>
>> ---
>>   mm/hugetlb_cgroup.c |   81 +++++++++++++++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 79 insertions(+), 2 deletions(-)
>> 
>> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
>> index 48efd5a..9458fe3 100644
>> --- a/mm/hugetlb_cgroup.c
>> +++ b/mm/hugetlb_cgroup.c
>> @@ -99,10 +99,87 @@ static void hugetlb_cgroup_destroy(struct cgroup *cgroup)
>>   	kfree(h_cgroup);
>>   }
>> 
>> +
>> +static int hugetlb_cgroup_move_parent(int idx, struct cgroup *cgroup,
>> +				      struct page *page)
>> +{
>> +	int csize;
>> +	struct res_counter *counter;
>> +	struct res_counter *fail_res;
>> +	struct hugetlb_cgroup *page_hcg;
>> +	struct hugetlb_cgroup *h_cg   = hugetlb_cgroup_from_cgroup(cgroup);
>> +	struct hugetlb_cgroup *parent = parent_hugetlb_cgroup(cgroup);
>> +
>> +	if (!get_page_unless_zero(page))
>> +		goto out;
>
> It seems this doesn't necessary...this is under hugetlb_lock().

already updated.

>
>> +
>> +	page_hcg = hugetlb_cgroup_from_page(page);
>> +	/*
>> +	 * We can have pages in active list without any cgroup
>> +	 * ie, hugepage with less than 3 pages. We can safely
>> +	 * ignore those pages.
>> +	 */
>> +	if (!page_hcg || page_hcg != h_cg)
>> +		goto err_out;
>> +
>> +	csize = PAGE_SIZE<<  compound_order(page);
>> +	if (!parent) {
>> +		parent = root_h_cgroup;
>> +		/* root has no limit */
>> +		res_counter_charge_nofail(&parent->hugepage[idx],
>> +					  csize,&fail_res);
>                                               ^^^
> space ?

I don't have code this way locally, may be a mail client error ?

>
>> +	}
>> +	counter =&h_cg->hugepage[idx];
>> +	res_counter_uncharge_until(counter, counter->parent, csize);
>> +
>> +	set_hugetlb_cgroup(page, parent);
>> +err_out:
>> +	put_page(page);
>> +out:
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Force the hugetlb cgroup to empty the hugetlb resources by moving them to
>> + * the parent cgroup.
>> + */
>>   static int hugetlb_cgroup_pre_destroy(struct cgroup *cgroup)
>>   {
>> -	/* We will add the cgroup removal support in later patches */
>> -	   return -EBUSY;
>> +	struct hstate *h;
>> +	struct page *page;
>> +	int ret = 0, idx = 0;
>> +
>> +	do {
>> +		if (cgroup_task_count(cgroup) ||
>> +		    !list_empty(&cgroup->children)) {
>> +			ret = -EBUSY;
>> +			goto out;
>> +		}

Is this check  going to moved to higher levels ? Do we still need
this. Or will that happen when pred_destroy becomes void ?

>
>> +		/*
>> +		 * If the task doing the cgroup_rmdir got a signal
>> +		 * we don't really need to loop till the hugetlb resource
>> +		 * usage become zero.
>> +		 */
>> +		if (signal_pending(current)) {
>> +			ret = -EINTR;
>> +			goto out;
>> +		}
>
> I'll post a patch to remove this check from memcg because memcg's rmdir
> always succeed now. So, could you remove this ?

Will drop this 

>
>
>> +		for_each_hstate(h) {
>> +			spin_lock(&hugetlb_lock);
>> +			list_for_each_entry(page,&h->hugepage_activelist, lru) {
>> +				ret = hugetlb_cgroup_move_parent(idx, cgroup, page);
>> +				if (ret) {
>
> When 'ret' should be !0 ?
> If hugetlb_cgroup_move_parent() always returns 0, the check will not be necessary.
>

I will make this void funciton.

-aneesh

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ