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

[Qais Yousef]

On 10/30/26 10:50, Christian Loehle wrote:
> On 10/29/26 23:43, Qais Yousef wrote:
> > On 10/29/26 15:58, Christian Loehle wrote:
> > 
> >>> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> >>> index 76f3c84ca6846..84301fc49e699 100644
> >>> --- a/kernel/sched/idle.c
> >>> +++ b/kernel/sched/idle.c
> >>> @@ -502,6 +502,25 @@ static void set_next_task_idle(struct rq *rq, struct task_struct *next, enum snt
> >>>        * lost_idle_time of clock_pelt
> >>>        */
> >>>       update_idle_rq_clock_pelt(rq);
> >>> +
> >>> +    /*
> >>> +     * Due to a race condition when enabling sched_uclamp_used static key,
> >>> +     * we can end up with imbalance where uclamp_rq_inc_id() has happened
> >>> +     * on a CPU without uclamp_rq_dec_id() on another CPU that hasn't seen
> >>> +     * the static key flipped. The race condition is unlikely, but ensure
> >>> +     * the uclamp_rq() state is set properly on each entry to idle.
> >>> +     *
> >>> +     * The reset will cause the uclamp_max from uclamp_idle_value() to be
> >>> +     * lost. Since we are imbalanced, hard to know what is right. So just
> >>> +     * cleanup. This should be a transient error state once we recover
> >>> +     * everything should work as expected.
> >>> +     *
> >>> +     * We need to be careful of some paths that can force idle with tasks
> >>> +     * are still queued.
> >>> +     */
> >>> +    if (uclamp_is_used() &&
> >>> +        !rq->nr_running && unlikely(!uclamp_rq_is_idle(rq)))
> >>
> >> just checking nr_running isn't enough as CFS bandwidth throttling (a fun one
> >> recently!) will decrement it through dequeue_task_fair() without calling
> >> uclamp_rq_dec(), i.e. it's clamps must remain valid AFAICS.
> > 
> > I think this and the rt group throttling are false positives. Do they actually force idle or just under contention dequeue the task temporarily to allow other queued tasks to run?
> 
> It forces idle, I can reproduce active=1 and bucket->tasks=0 and the WARN_ON_ONCE triggers:
> 
> [  329.665099] WARNING: kernel/sched/core.c:1845 at uclamp_rq_dec_id+0x10c/0x1dc, CPU#5: systemd-journal/281
> [  329.679279] Modules linked in:
> [  329.682333] CPU: 5 UID: 0 PID: 281 Comm: systemd-journal Tainted: G S                   7.3.0-uclamp-cfs-repro-20261030 #2 PREEMPT_RT 
> [  329.694411] Tainted: [S]=CPU_OUT_OF_SPEC
> [  329.698323] Hardware name: Radxa Computer (Shenzhen) Co., Ltd. Radxa Orion O6/Radxa Orion O6, BIOS 1.1.0-1 2025-12-25T02:55:53+00:00
> [  329.710222] pstate: 834000c9 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> [  329.717174] pc : uclamp_rq_dec_id+0x10c/0x1dc
> [  329.721524] lr : uclamp_rq_dec_id+0x98/0x1dc
> [  329.725786] sp : ffff800081bb3a80
> [  329.729089] x29: ffff800081bb3a90 x28: 0000000000000001 x27: ffffb54253580c40
> [  329.736219] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
> [  329.743348] x23: 0000000000000000 x22: ffff000085462380 x21: ffff0001fb6e2c40
> [  329.750478] x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000
> [  329.757606] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> [  329.764736] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000000
> [  329.771865] x11: 0000000000000000 x10: 006c616e72756f6a x9 : 0000000000000000
> [  329.778993] x8 : 006c616e72756f6a x7 : ffff000085462380 x6 : 0000000000000001
> [  329.786122] x5 : 00000000000000e1 x4 : ffff4abfa8162000 x3 : ffff0001fb6e2c40
> [  329.793251] x2 : 000000000000000c x1 : 0000000000000000 x0 : 0000000000000000
> [  329.800380] Call trace:
> [  329.802816]  uclamp_rq_dec_id+0x10c/0x1dc (P)
> [  329.807168]  dequeue_task+0x54/0x134
> [  329.810737]  __schedule+0x6b0/0x1018
> [  329.814307]  schedule+0x34/0xd4
> [  329.817440]  schedule_hrtimeout_range_clock+0x108/0x11c
> [  329.822657]  schedule_hrtimeout_range+0x14/0x20
> [  329.827179]  do_epoll_wait+0x47c/0x594
> [  329.830922]  do_compat_epoll_pwait.part.0+0x14/0xb4
> [  329.835792]  __arm64_sys_epoll_pwait+0x74/0x114
> [  329.840314]  invoke_syscall+0x54/0x108
> [  329.844055]  el0_svc_common.constprop.0+0xc0/0xe0
> [  329.848750]  do_el0_svc+0x1c/0x28
> [  329.852055]  el0_svc+0x38/0x250
> [  329.855189]  el0t_64_sync_handler+0xa0/0xe4
> [  329.859363]  el0t_64_sync+0x17c/0x180
> [  329.863018] ---[ end trace 0000000000000000 ]---

Okay, thanks for checking.

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.