Re: Uclamp races due to non-atomic static_branch_likely updates

[Peter Zijlstra]

On Wed, Oct 21, 2026 at 02:20:58PM +0100, Qais Yousef wrote:

> > Also note that a simple global boolean has the exact same problem.
> > Adding runtime conditionals isn't going to fix this.
> 
> I have something in my memory that could be complete garbage that tells me all
> cpus should see the new update after a grace period, did my brain invent this?

This is true; rcu_sync() implies a memory barrier on all CPUs, and
therefore all CPUs must observe the prior state upon completion.

The thing is that a grace period is of 'arbitrary length' and during
that you can still have some CPUs seeing your variable set while others
will not and you get into the very same problem.

> If not invented, can we do synchronize_rcu() once on any cpu seeing the code
> enabled for the first time to ensure the rest of the cpus has seen the newly
> enabled path?
> 
> eg (not even compile tested):
> 
> 	diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> 	index 7d2ec527b8a2..a6093ec88103 100644
> 	--- a/kernel/sched/sched.h
> 	+++ b/kernel/sched/sched.h
> 	@@ -3715,7 +3715,16 @@ unsigned long uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
> 	  */
> 	 static inline bool uclamp_is_used(void)
> 	 {
> 	-       return static_branch_likely(&sched_uclamp_used);
> 	+       if (static_branch_likely(&sched_uclamp_used)) {
> 	+               static bool do_once = true;
> 	+               if (unlikely(do_once)) {
> 	+                       do_once = false;
> 	+                       synchronize_rcu();
> 	+               }
> 	+               return true;
> 	+       }
> 	+
> 	+       return false;
> 	 }
> 
> 	 /*

This cannot work; two immediate problems:

 - the do_once needs re-evaluating for every switch
 - you cannot do rcu_sync while holding rq->lock ;-)

> The other alternative is to just accept this race can happen and do some sanity
> check and reset/cleanup on going to idle - which should be pretty cheap and
> straightforward.

This seems the sanest option.