linux-kernel - Re: [PATCH v3] cgroup: Add pids controller event when fork fails because of pid limit

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]

Date:	Tue, 21 Jun 2016 17:23:40 +0000
From:	Kenny Yu <kennyyu@...com>
To:	Tejun Heo <tj@...nel.org>
CC:	"lizefan@...wei.com" <lizefan@...wei.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	"cyphar@...har.com" <cyphar@...har.com>,
	"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v3] cgroup: Add pids controller event when fork fails
 because of pid limit

Thanks for the feedback Tejun!

On 6/21/16, 1:12 PM, "Tejun Heo" <htejun@...il.com on behalf of tj@...nel.org> wrote:

>Hello,
>
>Just a couple nits.
>
>On Tue, Jun 21, 2016 at 09:56:38AM -0700, Kenny Yu wrote:
>> Summary:
>
>No need for "Summary:" tag.
>
>> This patch adds more visibility into the pids controller when the controller
>> rejects a fork request. Whenever fork fails because the limit on the number of
>> pids in the cgroup is reached, the controller will log this and also notify the
>> newly added cgroups events file. The `max` key in the events file represents
>> the number of times fork failed because of the pids controller.
>> 
>> This change also adds an atomic boolean to prevent logging too much (e.g. a fork
>> bomb). The message is logged once per cgroup until the next time the pids limit
>> changes.
>
>The above paragraph isn't uptodate anymore.

Thanks! Will change.

>
>> @@ -213,10 +220,23 @@ static int pids_can_fork(struct task_struct *task)
>>  {
>>  	struct cgroup_subsys_state *css;
>>  	struct pids_cgroup *pids;
>> +	int err;
>> +	int events_limit;
>>  
>>  	css = task_css_check(current, pids_cgrp_id, true);
>>  	pids = css_pids(css);
>> -	return pids_try_charge(pids, 1);
>> +	err = pids_try_charge(pids, 1);
>> +	if (err) {
>> +		events_limit = atomic64_inc_return(&pids->events_limit);
>> +		cgroup_file_notify(&pids->events_file);
>> +		/* Only log the first time events_limit is incremented. */
>> +		if (events_limit == 1) {
>> +			pr_info("cgroup: fork rejected by pids controller in ");
>> +			pr_cont_cgroup_path(task_cgroup(current, pids_cgrp_id));
>> +			pr_cont("\n");
>> +		}
>> +	}
>> +	return err;
>>  }
>
>It'd be better to use atomic64_inc_and_test() instead.
>
>	if (err) {
>		if (atomic64_inc_and_test()) {
>			pr_xxx...;
>		}
>		cgroup_file_notify(&pids->events_file);
>	}
>

According to the docs https://www.kernel.org/doc/Documentation/atomic_ops.txt ,
it looks like atomic_inc_and_test returns "a boolean indicating whether the resulting
counter value was zero or not", which will only happen when the counter goes from
negative to 0. I'll keep it as atomic_inc_return and get rid of the temp variable.

>Thanks.
>
>-- 
>tejun

Thanks,
Kenny