linux-kernel - Re: [PATCH v2] sched/fair: set burst to 0 when remove the restriction on cfs bandwidth

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: <22653c39-93a5-4958-a6fc-e31885f49373@huawei.com>
Date: Tue, 9 Jul 2024 12:04:56 +0800
From: Cheng Yu <serein.chengyu@...wei.com>
To: Tejun Heo <tj@...nel.org>
CC: <mingo@...hat.com>, <peterz@...radead.org>, <juri.lelli@...hat.com>,
	<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
	<rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
	<bristot@...hat.com>, <vschneid@...hat.com>,
	<changhuaixin@...ux.alibaba.com>, <shanpeic@...ux.alibaba.com>,
	<dtcccc@...ux.alibaba.com>, <vishalc@...ux.ibm.com>,
	<linux-kernel@...r.kernel.org>, <zhangqiao22@...wei.com>,
	<judy.chenhui@...wei.com>, <yusongping@...wei.com>, <zhaowenhui8@...wei.com>
Subject: Re: [PATCH v2] sched/fair: set burst to 0 when remove the restriction
 on cfs bandwidth

Hi,

On 2024/7/9 2:08, Tejun Heo wrote:
> Hello,
> 
> On Mon, Jul 08, 2024 at 08:00:53PM +0800, Cheng Yu wrote:
>> From: Zhao Wenhui <zhaowenhui8@...wei.com>
>>
>> In the cpu subsystem of cgroup v1 and v2, we set the restriction on cfs
>> bandwidth by setting the quota and burst value. Later, when we remove
>> the restriction by setting the quota to the default value, the burst
>> value should also be forced to the its default value of zero.
> 
> Explaining a bit why burst value should become zero can be helpful - ie.
> what happens when quota is not set but burst is limited?

When the restriction on cfs bandwidth is removed, the purpose of setting
burst value to zero is to avoid ambiguity.

> 
> ...
>> @@ -10840,6 +10840,12 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota,
>>  				     burst + quota > max_cfs_runtime))
>>  		return -EINVAL;
>>  
>> +	/*
>> +	 * Ensure burst equals to zero when quota is -1.
>> +	 */
>> +	if (quota == RUNTIME_INF && burst)
>> +		return -EINVAL;
> 
> This happening would be a bug, right? Would it make more sense to use
> WARN_ON_ONCE()?

As Vishal Chourasia mentioned, it can prevent setting excessively large
burst value. Using WARN_ON_ONCE() does not have this effect.

> 
> Thanks.
> 

Thanks
--
Cheng Yu