Re: [PATCH v4 1/2] sched/uclamp: Fix race condition leading to imbalanced uclamp_rq

[Qais Yousef]

On 10/30/26 13:15, Peter Zijlstra wrote:
> On Fri, Oct 30, 2026 at 11:28:25AM +0000, Qais Yousef wrote:
> 
> > Peter/Vincent, what do you think? It seems we have a schrodenger task that is
> > both enqueued and dequeued simultaneously in these throttling paths. Shouldn't
> > this be fixed? If yes, any thoughts on the right approach? Should we throttle
> > if there are no other tasks on the rq too? I didn't realize the semantics are
> > that strong for enforcing the quota.
> 
> Urgh, nothing is ever straight forward is it ...

Exactly my thoughts..

> 
> Bah, so this is because the core does uclamp (for classes that have it
> on) but then the class does the throttle without going through the core
> {en,de}queue.
> 
> Does it make sense to have throttle_Cfs_rq_work() and tg_unthrottle_up()
> do uclamp_rq_{dec,inc}() respectively, along with the
> {de,en}queue_task_fair() they're already doing?

Yes it does, just wanted to make sure we agree the bug is there rather than in
the current patchset approach.

I remember seeing a patch to remove the uclamp_enabled bit and defer to
enqueue/dequeue_task_$class to handle this instead. Maybe I can revive it if it
makes more sense to go that way.

Let me find the path of least resistance and add it to the stack. Not sure we
want to tag as Fixes for LTS to pick up this independent fix. Note we have rt
group throttling path flagged up - which I also thought was false positive but
not sure anymore - but it seems to do partial dequeue and must be fixed in that
regard anyway even if it doesn't force idle.