Re: Uclamp races due to non-atomic static_branch_likely updates

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Oct 20, 2026 at 03:29:33PM -0400, Steven Rostedt wrote:
> On Tue, 20 Oct 2026 11:53:47 -0700
> John Stultz <jstultz@google.com> wrote:
> 
> > Maybe should the jump_label_update() logic be using something like
> > stop_machine? Or should there still be a conditional on key->enabled
> > in the unlikely case to make the behavior consistent? Or is there just
> > something about the uclamp usage that is off?
> 
> There's never been any guarantee that all call sites would update
> atomically. The first user of jump labels was tracepoints and I really do
> not want stop machine involved with them.
> 
> Perhaps we could add an api like static_key_enable_atomic() and
> static_key_disable_atomic() that would go through a stop_machine() and
> update everything that way for those locations that need an atomic view of
> the updated jump labels.

Argh, no, we do not want people to 'accidentally' add stop_machine()
usage, which we then have to spend tons of time on removing again.

And yeah, its always been the case that jump_labels (and static_branch)
updates are non-atomic. Most of them are init time, and don't care.

Now, I'm sure we've ran into this particular problem before, and it
always requires care.

Also note that a simple global boolean has the exact same problem.
Adding runtime conditionals isn't going to fix this.