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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZowrFHHXNds36Nsb@slm.duckdns.org>
Date: Mon, 8 Jul 2024 08:08:20 -1000
From: Tejun Heo <tj@...nel.org>
To: Cheng Yu <serein.chengyu@...wei.com>
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

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?

...
> @@ -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()?

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ