linux-kernel - Re: [PATCH] sched/fair: Prevent cfs_rq from being unthrottled with zero runtime

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] [day] [month] [year] [list]

Message-ID: <20251016114603.GC32@bytedance>
Date: Thu, 16 Oct 2025 19:46:03 +0800
From: Aaron Lu <ziqianlu@...edance.com>
To: Hao Jia <jiahao.kernel@...il.com>
Cc: Valentin Schneider <vschneid@...hat.com>,
	Ben Segall <bsegall@...gle.com>,
	K Prateek Nayak <kprateek.nayak@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Chengming Zhou <chengming.zhou@...ux.dev>,
	Josh Don <joshdon@...gle.com>, Ingo Molnar <mingo@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Xi Wang <xii@...gle.com>, linux-kernel@...r.kernel.org,
	Juri Lelli <juri.lelli@...hat.com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>, Mel Gorman <mgorman@...e.de>,
	Chuyi Zhou <zhouchuyi@...edance.com>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Florian Bezdeka <florian.bezdeka@...mens.com>,
	Songtang Liu <liusongtang@...edance.com>,
	Chen Yu <yu.c.chen@...el.com>,
	Matteo Martelli <matteo.martelli@...ethink.co.uk>,
	Michal Koutný <mkoutny@...e.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [PATCH] sched/fair: Prevent cfs_rq from being unthrottled with
 zero runtime_remaining

On Thu, Oct 16, 2025 at 07:04:30PM +0800, Hao Jia wrote:
> On 2025/10/16 17:23, Aaron Lu wrote:
... ...
> > With the above said, this shouldn't matter anymore but just out of
> > curiosity: did you notice this by inspecting the code or actually
> > hitting the warning about using an outdated rq clock?
> > 
> > Per my understanding, most likely: __assign_cfs_rq_runtime() in
> > throttle_cfs_rq(cfs_rq) will grant 1ns runtime to cfs_rq so it won't
> > reach tg_throttle_down(). The comment I added above that if condition
> > is kind of misleading though.
> 
> 
> I did encounter this once.
> 
> perhaps in the following corner case:
> 
> If cfs_b->quota is set low (and quota is set at each level), and there are a
> large number of CPUs.
> 
> After tg_set_cfs_bandwidth()->__refill_cfs_bandwidth_runtime(), we release
> cfs_b->lock. cfs_b->runtime might be consumed by cfs_rq on other CPUs.

Ah I see. So I suppose in your setup, tasks are already started and then
quota is set.

> 
> Then, on one online CPU, we can't get 1ns runtime via
> __assign_cfs_rq_runtime(). Current limiting is triggered on this CPU, and
> tg_throttle_down()->rq_clock_pelt() is called.
> 

Got it, thanks for the info!