linux-kernel - Re: [PATCH v2] selftests/cgroup: improve the accuracy of cpu.max tests

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: <aGebynaCuASn3t4s@JPC00244420>
Date: Fri, 4 Jul 2025 18:15:54 +0900
From: Shashank Balaji <shashank.mahadasyam@...y.com>
To: Michal Koutný <mkoutny@...e.com>
Cc: Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
	Shuah Khan <shuah@...nel.org>, cgroups@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
	Shinya Takumi <shinya.takumi@...y.com>
Subject: Re: [PATCH v2] selftests/cgroup: improve the accuracy of cpu.max
 tests

On Fri, Jul 04, 2025 at 06:07:12PM +0900, Shashank Balaji wrote:
> Hi Michal,
> 
> On Fri, Jul 04, 2025 at 10:59:15AM +0200, Michal Koutný wrote:
> > On Fri, Jul 04, 2025 at 03:49:58PM +0900, Shashank Balaji <shashank.mahadasyam@...y.com> wrote:
> > > > 1. We don't need to separately check user_usec because it'll always be
> > > > less than user_usec^W usage_usec, and usage_usec is what's directly
> > > > affected by throttling.
> > 
> > When kernel is not preemptible, I'd expect the system time may more
> > easily excess the quota, so I considered the user_usage check less prone
> > to false results. But...
> > 
> > > > 2. I changed the >= to > because, not that it'll ever happen, but we can
> > > > let usage_usec = expected_usage_usec pass. Afterall, it's called
> > > > "expected" for a reason.
> > > 
> > > Hmm, here is something interesting. The following patch adds printfs to the
> > > existing code to see what user_usec, usage_usec, the expected_usage_usec used in
> > > the code, and the theoretical expected_usage_usec are. On running the modified test
> > > a couple of times, here is the output:
> > 
> > ...thanks for checking. I was misled by the previous test implementation
> > (the expected_usage_usec had no relation to actual throttled usage in
> > there). What you observe is thus likely explained by the default
> > sched_cfs_bandwidth_slice (5 times the tested quota) and CONFIG_HZ.
> > 
> > So I'd say keep only the two-sided tolerant check. (I want to avoid the
> > test to randomly fail when there's no gaping issue.)
> 
> Yep, patch v2 is doing just that. So, I assume I have your Acked-by?
> 
> Thanks
> 
> Shashank

I forgot to add the fixes tags:
Fixes: a79906570f9646ae17 ("cgroup: Add test_cpucg_max_nested() testcase")
Fixes: 889ab8113ef1386c57 ("cgroup: Add test_cpucg_max() testcase")

Should I send a v3 with your ack and the tags?

Thanks

Shashank